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OFFICE MEMO HF Digital Bibliography Date:10/10/94 
Someone on the Ham Digital newsgroup was looking for info on PACTOR the other 
day. This prompted me to go through my files and prepare a bibliography. 
This was limited, for the most part, to the ham periodical literature. I 
specifically excluded professional journals and books as these can be easily 
located through normal liberary research techniques. Thought it might be 
interesting to the hfsig too. Did I miss any "good ones"? 
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Message-ID: <54FDDFE3172@frl.orst.edu> 


Hi all, 


I have put a posting out on Usenet for more on an "HF channel simulator" and 
have received some (not much though) feedback. There apparently are narrow 
band and wide band simulators, the latter being for spread spectrum (SS) 
applications and there are some interest presently by the military in this. 
We are mostly interested in a narrow-band simulator, that, by the way, can 
be a very complex thing if indeed you want to simulate the behavior at a 
particular location at aparticular instant in time. Those of you that have 
played with"IONCAP" and similar program will have some idea what this 
involves. There is also a much simpler simulation using the CCIR "good" and 
"poor" recommendations. These models allows one to adjust S/N settings and 
allows the modem to be evaluated in alittle as 0.1 dB steps. I have some 
scanty specs on the CCIR model can anyone help with obtaining a copy of 
this? (It is in the Dubrovnic plenary session, ca. 1989). 


Otherwise, I am in the process of bringing up a 100 baud QPSK single tone 
modem. It is possible that such an arrangement using two parallel channels 
will allow robust 400 bps using a regular RTTY channel bandwidth (without 
coding with Golay (24,12) the rate would be 200 bps). This code will run 
on the Cardinal soundcard. The CCIR channel simulator will also run on the 
Cardinal sound card. 


Does anyone have any ideas on spread spectrum implementations for HF? 


I have not heard much from anyone being interested in participating in code 
development. You are missing out on some very interesting and educational 
opportunities. If I you are interested, let us hear from you. 


73's 


Johan 

KC7WW 
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Hi 


I realize this is not the current topic, but a list of BBSs which 

have ports on 2 or more frequencies would be of some value. THe BBSSIG is 
making a table of states/substate identifiers and a list of these 

hf net interconnects would be of value. 


Does someone have such a list? 
Could we build one for first hand information? 


I am willing to compile this list if that will help. 


73 Barry 
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Date: Tue, 18 Oct 1994 10:13:11 -0700 (PDT) 
From: Hugh Shane <shane@mdd.comm.mot.com> 
X-Sender: shane@daffyduck 
To: hfsig@tapr.org 
Cc: hfsig@tapr.org 
Subject: Re: [HFSIG:14] High Speed HF modem progress 
In-Reply-To: <54FDDFE3172@frl.orst.edu> 
Message-Id: <Pine.SUN.3.90.941018095228 .29382K-100000@daffyduck> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


Johan, 


Forgive the delay in responding to your recent postings. They contain a 
lot of information and it's taken me some time to hoist in even part of 
it! 


> 
> I have put a posting out on Usenet for more on an "HF channel simulator" and 
> have received some (not much though) feedback. There apparently are narrow 


I did a literature search on the University of Washington's online 
catalog and couldn't find a single reference to HF channel simulators. I 
haven't had a chance to manually search the IEEE index. 


> allows the modem to be evaluated in alittle as 0.1 dB steps. I have some 
> scanty specs on the CCIR model can anyone help with obtaining a copy of 
> this? (It is in the Dubrovnic plenary session, ca. 1989). 


If you can send some more information I'll try the UoW engineering library. 


Otherwise, I am in the process of bringing up a 100 baud QPSK single tone 
modem. It is possible that such an arrangement using two parallel channels 
will allow robust 400 bps using a regular RTTY channel bandwidth (without 
coding with Golay (24,12) the rate would be 200 bps). This code will run 
on the Cardinal soundcard. The CCIR channel simulator will also run on the 
Cardinal sound card. 


VV VV VV WV 


The sound card seems like a good approach. TAPR's DSP-93 is pricey and 
has a long delivery time. 


> 
> Does anyone have any ideas on spread spectrum implementations for HF? 


I've done some work with narrow-band spread spectrum transmission of 
digital video over wireline. (This was some years ago and so we were doing 
everything in hardware. These days a run of the mill DSP could do the same 
thing.) This approach may be applicable to HF but I have no experience 
with this application. One observation I could make is that the scheme we 
used seemed to be quite sensitive to the phase distortion of the channel. 
I suspect the phase distortion of the HF channel is going to present a 
challenge regardless of the modulation scheme we pick. 


> I have not heard much from anyone being interested in participating in code 
> development. You are missing out on some very interesting and educational 
> opportunities. If I you are interested, let us hear from you. 


Please count me in! What's the first task you have in mind? 


Hugh 
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To: hfsig <hfsig@tapr.org> 
Subject: HF Channel Simulator 
Date: Tue, 18 Oct 94 13:35:00 EDT 
Message-Id: <2EA40772@arrl.org> 
Encoding: 15 TEXT 
X-Mailer: Microsoft Mail V3.0 


Johan -- I'm interested in the HF channel simulator project. I've ordered a 
copy of CCIR Rec. 520-1, which I think includes specifications for CCIR 
standard channels. In Kantronics' May, 1994 QEX article about G-TOR, they 
refer to an HF channel simulator they used to test their G-TOR system. This 
simulator used a TMC320C30 and implemented the "good, moderate, poor and 
flutter fading channels prescribed by the CCIR as recommended for simulator 
test channels." That seems like a good place to start. I should have the 
document in a week or so and will report here on what I find out about the 
CCIR standards. 


Then again, maybe I'm behind the power curve and the rest of you already 
know all about these CCIR recommended channels? 


-- Jon, KE3Z 
From jbloom@arrl.org Tue Oct 18 12:45:53 1994 
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X-Mailer: Microsoft Mail V3.0 


Oh, I should also mention that the November QEX editorial is about the need 
for HF channel simulation and refers to this mailing list, with instructions 
on how to access it. Maybe that'll drag a few more people into the mix. 


-- Jon 
From FORRERIJ@frl.orst.edu Tue Oct 18 13:50:01 1994 
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FL" <FORRERIJ@fr1l.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Tue, 18 Oct 1994 11:49:42 PST8PDT 

Subject: Re: [HFSIG:16] Re: High Speed HF modem progress 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <56A91835976@frl.orst.edu> 
Hi Hugh, 


I must apologize that we jumped into the deep end - if you are 
somewhat overwhelmed by the details, hang in there. 


The channel simulator would play an important and necessary role during 
evaluation. From re-reading Ken Wickwire's excellent QEX articles (ca. 
1992) and also from Freeman's handbook, I found that CCIR rep. 549-2 (XVI 


th Plenary Assembly, Dubnovrik, 1986, Vol III) contains a wealth on this 
topic. Likewise, have found that our library does not have these reports, 
so hopefully, someone else may be able to help out. I note that Jon may be 
able to help there - we will appreciate any efforts to locate this source 
of information. 


It is obvious that a full-blown channel simulator is a very 

complex thing, perhaps a project that someone could pursue, however, a 
simpler model, that perhaps includes multipath with variable delay, 

fading rate, channel bandwidth and S/N, may suffice to get us on the right 
track. It would be really great if we could establish a few norms for the 
known modulation schemes under such conditions and then direct efforts into 
those that are most promising. 


Regarding the DSP platform - the TAPR DSP-93 is a fine design and in time 
will establish a good base of users and applications. Personally I have 
found the DSP sound card approach quite attractive for development work 

and have collected a number of useful tools along the way. I also 

am interested in the possibilities of integrating this hardware into the 
mainstream OS. You probably are aware that there are some very innovating 
DSP- related API components under development that will come on-line in the 
near future. 


Presently I am working on DSP code subroutines that would be needed in 

just about all future demodulators - low distortion cosine and sine 
generators where carrier frequency and sample rate may be variable, i.e. 

for splitting a signal into its I/Q components, PLL's, Costa's loops etc. 

It becomes a relatively painless process to build demodulators - building 
good AGC, phase scynchronisers, bit clock extractors, however, still 

remains the challenge. This software uses, as a basis, the demo software for 
a sound card that accompanies an article that will feature in the November 
issue of QEX. I'll be happy to share the code with those experimenting with 
a Cardinal or Orchid sound card. 


>From your comments on SS, it appears that I need to do more homework on SS. 
It appears that once we get it to work, it may be the solution to many of 
our present problems. One question - does it mean that if we have found our 
efficient modulation scheme, that it is just a matter of implementing it 

on top of the SS coder/decoder? (pardon my ignorance). 


73's 


Johan 
KC7WW 


From Rick_Whiting@ATK.COM Tue Oct 18 15:52:30 1994 
Return-Path: <Rick_Whiting@ATK.COM> 
Received: from ATK.COM by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqxLVL-QQQQWEC; Tue, 18 Oct 94 15:51 CDT 
Received: from gateway1.ATK.COM by ATK.COM (5.65/1.34) 
id AA20157; Tue, 18 Oct 94 15:51:22 -0500 
Message-Id: <9410182051.AA20157@ATK.COM> 
Date: 18 Oct 1994 16:00:58 -0600 
From: "Rick Whiting" <Rick_Whiting@ATK.COM> 
Subject: Re: HF Channel Simulation 
To: "Post hfsig TAPR" <hfsig@tapr.org> 


Subject: Time:3:30 PM 
OFFICE MEMO RE>HF Channel Simulation Date:10/18/94 
I had our Engineering Library run a search of ITU/CCIR docs for HF channel 
simulation. Interestingly enough, they didn't hit on CCIR Radio Report 549-2 
but they did come back with: 


Recmn 520-1 Use of High Frequency Ionospheric Channel Simulators - Section 
3Ac - Influence of the Ionosphere. 


Recmn 520-2 (Same description as above). 
Recmn 549-3 (Same description as above). 


There were also references to other ITU/CCIR Reports on stuff like adaptive 
automatic HF radio systems (551-2), multi-frequency-shift keying techniques 
for HF (702), radiotelegraph circuits network architecture for HF data (995), 
use of coding diversity on HF data circuits (1132), etc. Looks like a wealth 
of info. The bad news is that none of these are in our library! 


By the way, one of my contacts at Alliant Techsystems' Signal Analysis Center 
in Annapolis suggested the accession citation of interest is CCIR Radio 
Report 549-2, "HF Ionospheric Regulations, Channel Simulators, Volume III." 
CCIR 549-2 was also mentioned by other "posters" to TAPR/hfsig. 


73/Rick WOTN 


From FORRERIJ@frl.orst.edu Wed Oct 19 11:14:41 1994 

Return-Path: <FORRERJ@frl.orst.edu> 

Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqxdet-Q000p4C; Wed, 19 Oct 94 11:14 CDT 

Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 

(8.6.9/8.6.9) with SMTP id BAAQOQ222 for <hfsig@tapr.org>; Wed, 19 Oct 1994 

01:53:32 -0700 

Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 


Wed, 19 Oct 94 9:14:34 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 19 Oct 94 9:14:27 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERIJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Wed, 19 Oct 1994 09:14:20 PST8PDT 
Subject: Re: [HFSIG:20] Re: HF Channel Simulation 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <57FFB412162@frl.orst.edu> 
Hi all, 


Thanks for all the good work being done on the channel simulation. I have 
been promised some additional documentation and also found out a bit more 
on folks doing this kind of work for a living. Soon as I have more to work 
with, I'll share the details. 


Jon's comment on looking at the QEX article on G-TOR reminded me that I 
spoke with Glenn Prescott at the last DCC. He is at the Univ. of Kansas and 
I guess that is where that 320C30-based simulator is located. Does anyone 
perhaps have Glenn's e-mail address? It may be worth dropping him a line. 


Glad to hear from you too Walt - I'll prepare a posting on what I use for 
DSP development work for those that wish to consider purchasing the 
right sound card option. 


Barry, have you gotten feedback yet on your posting on "2-port" HF 
capability? 


Take care, 


Johan 
KC7WW 
From g4guo@dircon.co.uk Wed Oct 19 15:32:04 1994 
Return-Path: <g4guo@dircon.co.uk> 
Received: from tdc.dircon.co.uk by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqxh£z-0001BcC; Wed, 19 Oct 94 15:31 CDT 

Received: from dircon.co.uk (tdc.dircon.co.uk) by tde.dircon.co.uk with SMTP id 
AA23850 

(5.67b/IDA-1.5 for <hfsig@tapr.org>); Wed, 19 Oct 1994 21:32:18 +0100 
Received: by dircon.co.uk (5.67b) id AA23846; Wed, 19 Oct 1994 21:32:16 +0100 
Date: Wed, 19 Oct 1994 21:32:15 +100 (BST) 
From: Charles Brain <g4guo@dircon.co.uk> 
Subject: H.F modems 
To: hfsig@tapr.org 
Message-Id: <Pine.3.89.9410192101 .A23693-0100000@tdc.dircon.co.uk> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


Hello, 


A good starting place for H.F modems is Proposed Federal Standard 1052. 
The main body of the standard describes a serial tone modem, Appendix A 
contains details of a parallel tone modem and Appendix B the Data Link 
Protocol. 

Also anyone developing Mil-Std-188-141A/ FS1045/1046 can get a DOS/Windows 
package to test it using a sound blaster card from ntia.its.bldrdoc.gov in 
dist/ale-cd. 

My main concern is on what frequencies these modems will be used? They use 
voice bandwidths so the C.W/RTTY frequencies are probably out and if you go 
into the voice portions you will be accused of being a slow scan operator! 

I would like to see channel adaption discussed, why bother getting the last 
db of performance when a lot more can be gained by moving to a new channel! 

I would be more interested in very robust slow speed modems i.e chirp. The 
company I work for have developed a chirp modem but I believe it uses about 
5x56000 dsps. 

Although I have ordered a DSP93 board I tend to think it really isn't 
powerful enough for more advanced modems. 

The 'in' thing appears to be parallel modems using soft decoding and 
Trellises. 


Regards Charles 


| 73 Charles H. Brain G4GUO 

| E-mail g4guo@dircon.co.uk 

| Tel Day (0245)353221 Xtn 3254 

| Eve (0245) 469382 | 
| TCP/IP g4guo.ampr.org AX25 g4suo@gb7esx 

| Snail 2 Daisy Court, North Springfield, Chelmsford. | 
| ESSEX. CM1 5QU. U.K | 


From barry@ia.net Wed Oct 19 15:51:51 1994 

Return-Path: <barry@ia.net> 

Received: from allanon.ia.net by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqxhz7-QQ001N8C; Wed, 19 Oct 94 15:51 CDT 

Received: from localhost (barry@localhost) by allanon.ia.net (8.6.5/8.6.5) id 

PAAO9357 for hfsig@tapr.org; Wed, 19 Oct 1994 15:51:15 -0500 

From: Barry Buelow - WAORJIT <barry@ia.net> 

Message-Id: <199410192051.PAA09357@allanon.ia.net> 

Subject: found CCIR 549-2 

To: hfsig@tapr.org 

Date: Wed, 19 Oct 1994 15:51:14 -0500 (CDT) 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 1327 


Hi all, 


I just received a copy of CCIR Report 549-2. It was faxed in here 
and is readable, but would not survive another fax. A paper copy is on 


the way and should be here in a few days. 
Quoting the Report 


"This Report describes a Gaussian-scatter HF channel model for multiplicative 
distortion, the expermiental method used to confirm the validity and the 
bandwidth limitation of this model, and one implementation of an HF 

simulator based on this model." 


The entire Report is about 9 pages and contains 3 figures, 2 nasty looking 
equations, 20 references, and 2 Annex(s) with 2 more figures. 


Figure 

Power Spectra of the multipath components of a CW signal. 
Block diagram of HF ionispheric channel models. 

Tap-gain spectra in validated Gaussian-scatter model. 
Recording the channel characteristics. 

Simulation of the channel using recorded characteristics. 


aABRWNRPR 


Johann, I'll mail you a copy of the Report when I get the real copy. 


FREE COPIES! 
Well sort of. The first 5 people who request a copy will get one free. 
Please be able to make some use of it! 


Hope this helps, 
Barry wa0Qrjt 


barry@ia.net I read this in the evenings. 
sys_bjb%afds@hobbes.cca.rockwell.com Stared at continuously 8-5 
Central time! 


From FORRERJ@frl.orst.edu Wed Oct 19 16:36:51 1994 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqxigi-0000d4C; Wed, 19 Oct 94 16:36 CDT 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id HAAO2506 for <hfsig@tapr.org>; Wed, 19 Oct 1994 
07:15:47 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Wed, 19 Oct 94 14:36:51 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 19 Oct 94 14:36:30 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 
Date: Wed, 19 Oct 1994 14:36:26 PST8PDT 
Subject: Re: [HFSIG:22] H.F modems 


Priority: normal 
X-mailer: PMail v3.0 (R1a) 
Message-ID: <58559841185@frl.orst.edu> 


Hello Charles, 


Nice to hear from you. You certainly are bringing up a number of issues 
that have resulted in the formation of this HFSIG - good for you! 


Let us entertain a few notions and bring everyone up to speed: The HF modems 
that Charles are mentioning are all in the family of standards built around 
MIL-STD-188. This includes a 39 parallel-tone, 16-parallel tone, and 8-ary 
FSK. The latter one is also known as the ALE format. NTIA makes a CD-ROM 
test source available, primarily for testing ALE equipment. Some of these 
modems are capable of 2400 bps (single channel or time-divison multiplexed) 
and are not shy about fully utilizing a 3kHz bandwidth channel. Several 
outfits are producing such modems, and they are quite pricey - at least out 
of reach for the usual radio amateur. In my opinion - (for what its worth) 
this is more or less brute force bandwidth & power to meet a specific 
objective. It is my belief that it is our challenge as radio amareurs to 
come up with something a bit more refined, superior in performance, and 
affordable. However, these documents makes a good source of information. 


The chirp modulation modems that Charles mentions, implements a form of 
narrow-band SS. I have a couple of papers from the IEE on the theory and 
implementation details (let me know if you are interested in the 
references). If you have ever dealt with chirp and chirp-z transforms, you 
will have some idea what this is all about. This kind of innovation gives me 
hope that something as innovative will eventually lead to better solutions. 


You are quite correct about the modern trend toward parallel modems and 
clever coding, and we are heading that way too - though, hopefully, by 
doing our homework first to find out what basic modulation scheme to 

use - this is the whole idea behind the simulator. Hopefully we will have 
this basic knowledge shortly and then be able to move on to working on 
coding theory and eventually protocol. 


In an earlier posting I provided a guestimate of the capabilities 

of a few modulation schemes (some including coding) and shown that a 

typical single-DSP platform would perhaps (just a guess) be able to handle 

a x4 parallel situation (using fairly conventional modulation schemes). I 
hope that we would be able to do at least as good as the CLOVER II 

system. I am pleased to hear that you took the plunge with the DSP-93 - keep 
us posted on your developments. 


Thanks for your input - keep them coming. 

73's 

Johan 

From FORRERJ@frl.orst.edu Wed Oct 19 16:39:21 1994 


Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 


(Smail3.1.28.1 #3) id mOqxij8-Q001EuC; Wed, 19 Oct 94 16:39 CDT 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id HAAOQ2514 for <hfsig@tapr.org>; Wed, 19 Oct 1994 
07:18:17 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Wed, 19 Oct 94 14:39:20 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 19 Oct 94 14:38:58 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Wed, 19 Oct 1994 14:38:55 PST8PDT 
Subject: Re: [HFSIG:23] found CCIR 549-2 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <585641372D4@frl.orst.edu> 
Barry, 
That is great news - looking forward seeing the document. 


Johan 

From barry@ia.net Wed Oct 19 18:05:51 1994 

Return-Path: <barry@ia.net> 

Received: from allanon.ia.net by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqxk4n-Q00119C; Wed, 19 Oct 94 18:05 CDT 

Received: from localhost (barry@localhost) by allanon.ia.net (8.6.5/8.6.5) id 

SAA10200 for hfsig@tapr.org; Wed, 19 Oct 1994 18:05:17 -0500 

From: Barry Buelow - WAORIT <barry@ia.net> 

Message-Id: <199410192305.SAA10200@allanon.ia.net> 

Subject: Re: [HFSIG:25] Re: found CCIR 549-2 

To: hfsig@tapr.org 

Date: Wed, 19 Oct 1994 18:05:16 -0500 (CDT) 

In-Reply-To: <585641372D4@frl.orst.edu> from "Johan Forrer 

FL" at Oct 19, 94 04:42:00 pm 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 606 


Johan 
Sorry I missed on your name! 
Send me a good address. 


Do you know anyone that works for Rockwell in Dallas? I got the 
company librarian here in Cedar Rapids to make a few calls. Seems 
like there might be other items of interest in the lib there, but 
searching via long distance is not effective. They are very good 
at the library tasks but I hate to take up their time. We get 
regular ethics lectures... 


I am also aware that the comm division does ALE and other hf 
"special" tasks. They might be able to help but are usually reluctant 
to go public with their knowledge. 


73 Barry waOrjt 


From shane@mdd.comm.mot.com Wed Oct 19 18:37:29 1994 
Return-Path: <shane@mdd.comm.mot.com> 
Received: from ftpbox.mot.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqxkZS-QQO01EAC; Wed, 19 Oct 94 18:37 CDT 
Received: from pobox.mot.com ([129.188.137.100]) by f£tpbox.mot.com with SMTP 
(5.67b/IDA-1.4.4/MOT-3.1 for <hfsig@tapr.org>) 
id AA19818; Wed, 19 Oct 1994 18:37:21 -0500 
Received: from mdd.comm.mot.com (mdisea.mdd.comm.mot.com) by pobox.mot.com with 
SMTP (5.67b/IDA-1.4.4/MOT-3.1 for <hfsig@tapr.org>) 
id AA17728; Wed, 19 Oct 1994 18:36:04 -0500 
Received: from daffyduck.mdd.comm.mot.com by mdd.comm.mot.com (4.1/SMI-4.1) 
id AA14097; Wed, 19 Oct 94 16:36:02 PDT 
Received: by daffyduck.mdd.comm.mot.com (4.1/SMI-4.1) 
id AA19268; Wed, 19 Oct 94 16:36:00 PDT 
Date: Wed, 19 Oct 1994 16:36:00 -0700 (PDT) 
From: Hugh Shane <shane@mdd.comm.mot.com> 
X-Sender: shane@daffyduck 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:19] Re: High Speed HF modem progress 
In-Reply-To: <56A91835976@f1r1.orst.edu> 
Message-Id: <Pine.SUN.3.90.941019161433 .29382f-100000@daffyduck> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Tue, 18 Oct 1994, Johan Forrer FL wrote: 


our present problems. One question - does it mean that if we have found our 
efficient modulation scheme, that it is just a matter of implementing it 
on top of the SS coder/decoder? (pardon my ignorance). 


VV VV NV 


Our wireline digital video transmission system convolved the data with a 
pseudo-noise data stream, converted this to analog, and put the resulting 
audio signal on the wire. On the receiving end, a correlation detector was 
used to recover the data. 


In an RF system the audio would simply be shifted to the desired RF 
spectrum using suppressed-carrier frequency-conversion techniques. It 
would be interesting to consider how one might do this up-conversion 
(and down conversion on the receiving end) digitally. In the HF bands 
we're talking about signals that some DSPs could handle. 


Well, more food for thought anyway &:) 


Hugh 
From shane@mdd.comm.mot.com Thu Oct 20 13:07:20 1994 
Return-Path: <shane@mdd.comm.mot.com> 
Received: from ftpbox.mot.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqy1tT-0001S1C; Thu, 20 Oct 94 13:07 CDT 
Received: from pobox.mot.com ([129.188.137.100]) by ftpbox.mot.com with SMTP 
(5.67b/IDA-1.4.4/MOT-3.1 for <hfsig@tapr.org>) 
id AA24690; Thu, 20 Oct 1994 13:07:09 -0500 
Received: from mdd.comm.mot.com (mdisea.mdd.comm.mot.com) by pobox.mot.com with 
SMTP (5.67b/IDA-1.4.4/MOT-3.1 for <hfsig@tapr.org>) 
id AA14906; Thu, 20 Oct 1994 11:01:43 -0500 
Received: from daffyduck.mdd.comm.mot.com by mdd.comm.mot.com (4.1/SMI-4.1) 
id AA17483; Thu, 20 Oct 94 09:01:40 PDT 
Received: by daffyduck.mdd.comm.mot.com (4.1/SMI-4.1) 
id AAQ2609; Thu, 20 Oct 94 09:01:39 PDT 
Date: Thu, 20 Oct 1994 09:01:39 -0700 (PDT) 
From: Hugh Shane <shane@mdd.comm.mot.com> 
X-Sender: shane@daffyduck 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:23] found CCIR 549-2 
In-Reply-To: <199410192051.PAA09357@allanon.ia.net> 
Message-Id: <Pine.SUN.3.90.941020085912 .29382k-100000@daffyduck> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Wed, 19 Oct 1994, Barry Buelow - WAORIT wrote: 


> 

> FREE COPIES! 

> Well sort of. The first 5 people who request a copy will get one free. 
> Please be able to make some use of it! 

> 


Dibs! And I'd be happy to reimburse you for copying and postage. Let me 
know how much. I'm hoping to be of assistance in designing and coding the 
channel simulator. 


Hugh Shane 
N7UAX 
2915 NE 52nd St #402 
Seattle, WA 98105 
From wdubose@sacdm01.kelly.af.mil Thu Oct 20 13:09:24 1994 
Return-Path: <wdubose@sacdm01.kelly.af.mil> 
Received: from sacdm01.kelly.af.mil by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqy1v9-0001S1C; Thu, 20 Oct 94 13:08 CDT 
Received: by sacdm01.kelly.af.mil (5.65b/1.0.2-rct) 
id AA16818; Thu, 20 Oct 94 13:00:40 -0500 
Message-Id: <9410201800.AA16818@sacdm01.kelly.af£.mil> 
Date: Thu, 20 Oct 94 13:00:25 -0500 


From: wdubose@sacdm01.kelly.af.mil (WALTER (WALT) D. DUBOSE - PKT) 
Subject: Introduction 
To: hfsig@tapr.org 


Greetings All, 
Let me introduce myself to the "net". 


I am presently employed by the USAF at Kelly AFB, San Antonio Air 
Logistics Center as Systems Manager for the Central Contracting 
Contract Data Management Host (spell that office automation). I 
retired from the AF Reserve in 1993 after 26 years in the reserve 
program. For the last 14 years in the program, I was Chief of 
Communications Maintenance for the 32nd Aeromedical Evacuation Group 
and senior communicator in the Aeromedical Evacuation System. 


During Desert Shield/Storm, I was Chief of Communications for the 
Theater Aeromedical Evacuation System and stationed in Saudi Arabia. 
The Aeromedical Evacuation System used HF communications exclusively 
for command and control communications. 


The year before Operation Just Cause, the "liberation" of Panama, the 
AF held an exercise which included having a NCS at Kelly AFB and an 
operational location in Panama. This, as we were to learn, a good 
practice for Operation Just Cause. During Just Cause, we learned that 
the 300 baud (Bell 102 Modem) communications we were using would xnotx* 
hack the communications needs for Aeromedical Evacuation (AE). We had 
begun using a 300 baud communications device/terminal almost 3 years 
before and it had connectivity problems from the first; however, it 
was so much better than voice (un-encrypted) communications that we 
put up with the downside. 


Because we fell flat with AE communications during Just Cause, our 
Major Command arranged a test of high speed data capability using 
Harris Corp, HF Comm Division's MIL-STD-188-110c modems and a NSA 
blackbox that used the MIL-STD 39 parallel tone modem in the winter of 
‘90 at Scott AFB. During the test we were able to pass 40K files over 
HF at 2400 and 4800 BPS with no trouble except for xBIG* QSBs, QRN and 
QRM. We would lose chunks for the file but what we received was 100% 
correct. No ARQ was used...just straight RATT (ASCII) with ProCom as 
the terminal program. 


The Major Command (MAJCOM) Chief Surgeon and MAJCOM AE Commander and 
my unit commander directed me to include a similar demonstration/test 
during AE's summer 90 exercise at Ft Hunter-Liggett, CA. I arranged 
for Harris and SAIC/SAIT to bring equipment (the MIL-STD modems and 
TEMPEST LapTop computers) to demonstrate high speed HF data 
transmission. We were networked the Navy Hospital Ship on the west 
Coast, Army and Air Force Medical Units and AE units on HF and 
compare the capability of our old equipment (300 baud, Bell 102) with 
the new modems running TCP/IP. 


SAIC/SAIT forgot that their software TCP/IP (probably KA9Q NOS) would 


be required to key the transmitter. Thus, we could only duplicate 
the previous demonstration but did confirm that 2400 and 4800 BPS 
data transmissions on HF were possible. 90 days after the exercise 
concluded, I was in Saudi. 


While in Saudi, we had the opportunity to use Harris ALE and 
MIL-STD-188-110c modems. The ALE was xNOT* suitable for our network 
operations (that's another story) and because our AE nets were much 
like NTS nets, I doubt that ALE will ever work on the hambands. 


HF high speed data transmissions did work and work very well. The 
robustness of these modems running at 2400 BPS at 100 watts provided 
better thruput than our 300 baud equipment running 1000 watts. Some 
units found that the MIL-STD modems on 100 watt transceivers worked 
better that 100/300 baud RATT (ASCII) at 20 KW. 


As one of the evaluators of Harris' AN/URC-119 (commercially known as 
the RF-350 series) HF equipment prior to production and having keep 
up my relationship with Harris technical personnel, I was privy to 
the technical information on their MIL-STD-188-110c modems. I also 
had the opportunity to evaluate Rockwell-Collins HF equipment that 
was similar to the Harris AN/URC-119 system. The MIL-STD, high 
speed, robust modems use external DSP technology in their modems to 
achieve the modem/transmission protocol. 


Almost a year ago, Lou, N5SGL, discovered some of Johan's (KC7WW) 

work and he and I began exchanging E-Mail about robust high speed HF 
modems using commercial-off-the-shelf£ (COTS) sound boards. During my 
many messages with Johan, I have come to believe that hams (those of 
you with a much high level of technical competency than I) can 
reproduce the MIL-STD modem/transmission protocols using a DSP/ASP DMA 
soundcard. 


One major question must be answered. Do we (hams) want to simply 
duplicate these proven MIL-STD modems (that cost a bundle) or roll 
our own along the same line. The MIL-STD modems BW will (just) fit 
into a SSB bandpass...but do we want something that wide? The will 
run 4800 BPS w/o the Reed-Solomon (RS) coding and 2400 with RS coding. 
How many BPS can we get using a 8 tone (narrow spaced tones), modem 
running 100 baud and can we keep the BW down to something that hams 

in general and the FCC will "buy"? Also, the cost of the "system" 
must be affordable. Should we use Golay or RS encoding for the FEC? 
Many questions to be answered. 


I believe we can obtain 1200 BPS with FEC and ARQ/CRC and 2400 BSP 
w/o FEC but with ARQ/CRC in a *ROBUST* modem protocol. I truly would 
like to see a TCP/IP HF WAN (SMTP only) to augment and eventually 
replace the HF NTS nets. 

73, 


Walt/K5YFW 


Snail-Mail Walt DuBose 
10909 Meadowhome 
San Antonio, Texas 78230 


MABELL HP 210-696-3196 
BP 210-925-6081 


VHF -FMx 146.46 (w/CTCSS 146.2) / 147.06 (w/CTCSS 203.5) 
UHF -FMx 446.0 (w/CTCSS 146.2) 

HF SSB Mobile 7.213 LSB 

HF CW (40/20) U_CALL_IT 


E-Mail k5yfw@sat.ampr.org (goes to k5yfw@k5yfw.ampr.org & k5yfw@sacdm10) 
(ham stuff...un-official...but important) 


E-Mail k5yfw@sacdm10.kelly.af.mil 
(semi-official...all mailgroups including hfsig) 


E-Mail wdubose@sacdm01.kelly.af.mil 
(official U.S. Government stuff and emergency communications) 


x Just in case you come San Antonio. 

From barry@ia.net Thu Oct 20 20:48:01 1994 

Return-Path: <barry@ia.net> 

Received: from allanon.ia.net by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqy95K-Q001dEC; Thu, 20 Oct 94 20:47 CDT 

Received: from localhost (barry@localhost) by allanon.ia.net (8.6.5/8.6.5) id 

UAA19886 for hfsig@tapr.org; Thu, 20 Oct 1994 20:47:39 -0500 

From: Barry Buelow - WAORJIT <barry@ia.net> 

Message-Id: <199410210147 .UAA19886@allanon.ia.net> 

Subject: Re: [HFSIG:28] Re: found CCIR 549-2 

To: hfsig@tapr.org 

Date: Thu, 20 Oct 1994 20:47:38 -0500 (CDT) 

In-Reply-To: <Pine.SUN.3.90.941020085912 .29382k-100000@daffyduck> from "Hugh 

Shane" at Oct 20, 94 01:14:00 pm 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 494 


Hey - you made the cut! 


73 Barry 


> 


> 
> 
> 
> On Wed, 19 Oct 1994, Barry Buelow - WAORIT wrote: 
> 
> 
> > FREE COPIES! 


2915 NE 52nd St #402 
Seattle, WA 98105 


> > Well sort of. The first 5 people who request a copy will get one free. 
> > Please be able to make some use of it! 

>> 

> 

> Dibs! And I'd be happy to reimburse you for copying and postage. Let me 
> know how much. I'm hoping to be of assistance in designing and coding the 
> channel simulator. 

> 

> Hugh Shane 

> N7UAX 

> 

> 

> 


From g4guo@dircon.co.uk Sat Oct 22 05:19:26 1994 
Return-Path: <g4guo@dircon.co.uk> 
Received: from tdc.dircon.co.uk by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqydXo-00005ZC; Sat, 22 Oct 94 05:19 CDT 
Received: from dircon.co.uk (tdc.dircon.co.uk) by tde.dircon.co.uk with SMTP id 
AA01823 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Sat, 22 Oct 1994 11:20:02 +0100 
From: Charles Brain <g4guo@dircon.co.uk> 
Received: by dircon.co.uk (5.67b) id AAQ1808; Sat, 22 Oct 1994 11:19:50 +0100 
Date: Sat, 22 Oct 1994 11:19:50 +0100 
Message-Id: <199410221019.AA01808@dircon.co.uk> 
To: hfsig@tapr.org 
Subject: Re: Z8530 and WB6YMH mod 


Charles Brain <g4guo@dircon.co.uk> writes: 
Hello Folks, 

I am desperatly trying to obtain details os WB6YMH's ‘trick' that allows 
a Z8530 SCC chip to act as a dumb serial/parallel converter. I am trying 
to take a serial synchronous bit stream from a modem and process it 
inside a P.C. !HELP! 


Regards Charles Brain G4GUO 


VV VV VV VV VV 


Vv 


| 73 Charles H. Brain G4GUO 

| E-mail g4guo@dircon.co.uk 

| Tel Day (0245)353221 Xtn 3254 

| Eve (0245) 469382 | 
| TCP/IP g4guo.ampr.org AX25 g4guo@gb7esx 

| Snail 2 Daisy Court, North Springfield, Chelmsford. | 
| ESSEX. CM1 5QU. U.K | 


VV VVVV VV 


> 

From g4guo@dircon.co.uk Sat Oct 22 05:19:36 1994 

Return-Path: <g4guo@dircon.co.uk> 

Received: from tdc.dircon.co.uk by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqydXx-Q0005ZC; Sat, 22 Oct 94 05:19 CDT 

Received: from dircon.co.uk (tdc.dircon.co.uk) by tde.dircon.co.uk with SMTP id 


AAQ1839 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Sat, 22 Oct 1994 11:20:14 +0100 
From: Charles Brain <g4guo@dircon.co.uk> 
Received: by dircon.co.uk (5.67b) id AAQ1817; Sat, 22 Oct 1994 11:19:57 +0100 
Date: Sat, 22 Oct 1994 11:19:57 +0100 
Message-Id: <199410221019.AA01817@dircon.co.uk> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:29] Introduction 


Hello Walter 


While in Saudi, we had the opportunity to use Harris ALE and 
MIL-STD-188-110c modems. The ALE was *xNOT* suitable for our network 
operations (that's another story) and because our AE nets were much 
like NTS nets, I doubt that ALE will ever work on the hambands. 


VVVV WV 


I would be really interested to know why you feel the ALE was unsuitable 
for this type of operation. Overhere in Europe we have our doubts as well 
but these are to do with the much higher levels of interference especially 
during daylight hours. 

Also are you talking about MIL_STD-188-141A or Harris's fast ALE system which 
is being developed as part of AHFDS (Advanced HF Data System). 

I believe that some form of narrower band ALE and RTCE is needed to try to spread 
activity away from 20 meters and towards the WARC/higher bands. 

I operate Clover from this QTH and so far have only worked stations on 20 meters 
even during times when the higher bands have been open. Our H.F bands are a 
wonderful 
resource that we are hardly even beging to use. I ask you AX25 on 20 meters! 
(Oophs sorry no protocol wars!!!). 


Regards Charles. 
From g4guo@dircon.co.uk Sat Oct 22 06:34:26 1994 
Return-Path: <g4guo@dircon.co.uk> 
Received: from tdc.dircon.co.uk by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqyeiJ-O000PuUC; Sat, 22 Oct 94 06:34 CDT 

Received: from dircon.co.uk (tdc.dircon.co.uk) by tde.dircon.co.uk with SMTP id 
AAQ5615 

(5.67b/IDA-1.5 for <hfsig@tapr.org>); Sat, 22 Oct 1994 12:34:32 +0100 
Received: by dircon.co.uk (5.67b) id AAQ5611; Sat, 22 Oct 1994 12:34:30 +0100 
Date: Sat, 22 Oct 1994 12:34:29 +100 (BST) 
From: Charles Brain <g4guo@dircon.co.uk> 
Subject: Re: [HFSIG:32] Re: Introduction 
To: hfsig@tapr.org 
In-Reply-To: <199410221019.AAQ1817@dircon.co.uk> 
Message-Id: <Pine.3.89.9410221244 .A5544-0100000@tdc.dircon.co.uk> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


Sorry I meant night time and begining! 


| 73 Charles H. Brain G4GUO 


E-mail g4guo@dircon.co.uk 
Tel Day (0245)353221 Xtn 3254 
Eve (0245) 469382 
TCP/IP g4guo.ampr.org AX25 gdguo@gb7esx 
Snail 2 Daisy Court, North Springfield, Chelmsford. 
ESSEX. CM1 5QU. U.K 


From k5yfw@k5yfw.ampr.org Sat Oct 22 09:22:30 1994 

Return-Path: <k5yfw@k5yfw.ampr.org> 

Received: from k5yfw.ampr.org by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqyhKy-0001rqC; Sat, 22 Oct 94 09:22 CDT 

Date: Sat, 22 Oct 94 08:42:56 CST 

Message-Id: <2111@k5yfw.ampr.org> 

From: k5yfw@k5yfw.ampr.org (Walter D. DuBose - K5YFW) 

Reply-To: k5yfw@sat.n5lyt.ampr.org 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:32] Re: Introduction 

In-Reply-To: Your message of Sat, 22 Oct 94 05:28 CDT 

X-Mailer: Bdale's Mailer version PA3AZK.940404 (MSDOS) 


Greetings Charles and All, 


In Charles message <199410221019.AA01817@dircon.co.uk> he writes: 
Hello Walter 


While in Saudi, we had the opportunity to use Harris ALE and 
MIL-STD-188-110c modems. The ALE was xNOT* suitable for our network 
operations (that's another story) and because our AE nets were much 
like NTS nets, I doubt that ALE will ever work on the hambands. 


VV VV WV 


I would be really interested to know why you feel the ALE was unsuitable 
for this type of operation. Overhere in Europe we have our doubts as well 
but these are to do with the much higher levels of interference especially 
during daylight hours. 

Also are you talking about MIL_STD-188-141A or Harris's fast ALE system which 
is being developed as part of AHFDS (Advanced HF Data System). 

I believe that some form of narrower band ALE and RTCE is needed to try to 
spread 
> activity away from 20 meters and towards the WARC/higher bands. 
> I operate Clover from this QTH and so far have only worked stations on 20 
meters 
> even during times when the higher bands have been open. Our H.F bands are a 
wonderful 
> resource that we are hardly even beging to use. I ask you AX25 on 20 meters! 
> (Oophs sorry no protocol wars!!!). 
> 
> Regards Charles. 


VVVV VV VV VV VV VV WV 


You have the correct MIL-STD referenced for the ALE we used. 


The Areomedical Evacuation (AE) net is much like a traffic net here 


in the U.S. (Please note I didn't say colonies Charles as I got 

a personal flame from a super patriot last time I used it...Hi Hi) 
We had up to 30 or so stations checked into the net on voice and 
when they need to pass traffic, they called the net station, got 
permission to call another station and then passed their traffic 
using a Bell 103, 300 baud, terminal device. This was the 

normal pre-ALE method. 


When we got ALEs on all our Harris HF radios, then the individual 
station would simply initiate an automatic connect with the station 
he wished to talk to and when voice contact was established, they 
would carry on in voice or with their terminal devices. Since 

there is muting on the audio in monitor mode and the ALE is scanning 
the 3 or 4 frequencies we were assigned, if another station needed 
to talk to another station, they pushed the connect button and the 
ALE went to the channel it had memorized as the place where the 
called station should be or started calling on each of the assigned/ 
programmed channels. If on any of those channels there was a 

voice or data QSO going on, it would place its signaling tone on 

the frequency it did not recognize it and "stepped" on the QSO. 

If critical AE data was being passed, it had to be 

re-transmitted. It really had a way of ruining a QSO as the 
signaling took many seconds of transmission time on each 

frequency to establish a connection. 


I am afraid that on crowed hambands, unless we have specific 
frequencies set aside for ALE signalling, we will incur the 
wrath of many hams. Also, this is compounded by the hidden 
transmitter effect...even if ALES were made smart enough to 
listen for signals and not transmit on channels/frequencies 
where a QSO existed...it might be able to hear only one side of 
a QSO thus stepping on the QSO. 


I hope I have explained the simply and adequately enough from an 
operational stand point rather than any technical standpoint. 


On another note, I notice that you say "Our H.F bands are a wonderful 
resource that we are hardly even beging to use." I did notice on 
several of my trips to Europe and while in Saudi that the HF 

bands there have xmuch* less activity than on this side of the 

pond. 


Reference AX.25 on 20 meters. Other than the lack of a good 
modem...and Johan, KC7WW and give you information on how to 
build a very good Bell 102 format modem to use on AX.25. 
However, you must remember that you cannot realiable receive 
data at over 100 or so baud on HF due to the ever present 
mulit-path signals...this should be covered in some of HALs 
writings. I have summerized some of these and am willing to 
place them here on the SIG if there is interest. 


Try going to 110 baud on AX.25 on 20 meters and see if you don't 
find the thruput much better. Also, run just one connected 


session on a frequency or limit it to xno morex than two connected 
sessions on a frequency. You may find the thuput comparible to 
100 baud RTTY/ASCII with no errors. 


73, Walt-k5yfw@home. today 


PS, Charles, notice I used the "American" spelling of meters... 
Hi Hi. -- k5yfw 
From g4guo@dircon.co.uk Sat Oct 22 11:59:38 1994 
Return-Path: <g4guo@dircon.co.uk> 
Received: from tdc.dircon.co.uk by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqyjn3-Q0004QC; Sat, 22 Oct 94 11:59 CDT 
Received: from dircon.co.uk (tdc.dircon.co.uk) by tde.dircon.co.uk with SMTP id 
AA04109 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Sat, 22 Oct 1994 17:57:36 +0100 
From: Charles Brain <g4guo@dircon.co.uk> 
Received: by dircon.co.uk (5.67b) id AAQ4088; Sat, 22 Oct 1994 17:57:33 +0100 
Date: Sat, 22 Oct 1994 17:57:33 +0100 
Message-Id: <199410221657 .AAO4088@dircon.co.uk> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:34] Re: ALE 


k5yfwe@k5yfw.ampr.org (Walter D. DuBose - K5YFW) writes: 
> Greetings Charles and All, 


If on any of those channels there was a 


> voice or data QSO going on, it would place its signaling tone on 
> the frequency it did not recognize it and "stepped" on the QSO. 
> If critical AE data was being passed, it had to be 

> re-transmitted. It really had a way of ruining a QSO as the 

> signaling took many seconds of transmission time on each 

> frequency to establish a connection. 

Hi Walter, 


0.K I understand about the problem, The fredricks ALE controller has 

a voice detect function, however as they are only using a TMS320C10 

I guess it is not very effective. As you say this is a problem. I have 
seen an intelligent squelch that uses a DSP in conjunction with a neural 
net to recognise speech on a channel, it takes a few hours to train though. 
Possibly some form of pilot tone SSB would be more suitable. Or the ALE 
could send a "Is the channel free call" I guess there are a lot of diffent 
things that could be done. 


As far as Chelmsford is concerned no I am not a member although I have 
been to the club a couple of times and I am friendly with one of the 
committe members. I will pass on your greetings. 

By the way I work at Mr Guglielmo's Wireless Works in Chelmsford. 


As far as packet is concerned I wonder if it would be possible to 

use a DSP based channel conditioner using the HDLC flags as a training 
sequence to reduce the multi-path problems. Also if a data frame has to be 
sent many times it may be possible to store multiple copies of the frame and 
do a majority vote on the data. It should be possible to do this without 


a change in the protocol. There is probably some flaw in my idea. 


I do think an improved packet protocol for HF is needed, I know a lot of people 
are thinking about the problem. I would favour a waveform similar to CLOVER 
i.e using a small number of tones to reduce baud rate and a priority ack protocol. 


As far as the English is concerned, my computer speaks Colonial English, anyway 
my father came from the Canadian Colony so I can just about understand you lot!! 


Regards Charles. 

From n7oo@huachuca-emh8.army.mil Sat Oct 22 18:08:37 1994 

Return-Path: <n7oo@huachuca-emh8.army.mil> 

Received: from huachuca-emh8.army.mil by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqypYA-O000vOC; Sat, 22 Oct 94 18:08 CDT 

Message-Id: <mOqypYA-0Q000vOC@dptspd.sat.datapoint.com> 


Date: Sat, 22 Oct 94 16:03:23 MST 
From: Jack Taylor <n7oo@huachuca-emh8.army.mil> 
To: hfsig@tapr.org 


Subject: Re: [HFSIG:35] Re: ALE 


Charles Brain suggests some changes could be made to ax.25 to make it more 
effective for HF operations. 


Be advised a revision to the ax.25 standard is "in the works" and is 
currently before the ARRL futures committee for review. If anyone is 
interested in looking over the proposed new ax.25 standard it is available 
via anonymous ftp from hereford.ampr.org /pub/hamradio/lapa.txt. If after 
review, comments wish to be made, they can be sent to one of the principle 
authors, bbeech@huachuca-emh8.army.mil. 


73 de Jack 
From gjones@tenet.edu Sat Oct 22 19:09:35 1994 
Return-Path: <gjones@tenet.edu> 


Received: from Kay-Abernathy.tenet.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqyqVA-Q001EuC; Sat, 22 Oct 94 19:09 CDT 

Received: (from gjones@localhost) by Kay-Abernathy.tenet.edu (8.6.9/8.6.9) id 

TAA23199 for hfsig@tapr.org; Sat, 22 Oct 1994 19:09:30 -0500 

From: Greg Jones <gjones@tenet.edu> 

Message-Id: <199410230009.TAA23199@Kay -Abernathy.tenet.edu> 

Subject: Re: [HFSIG:36] Re: ALE 

To: hfsig@tapr.org 

Date: Sat, 22 Oct 1994 19:09:29 -0500 (CDT) 

In-Reply-To: <mOqypYA-0000vOC@dptspd.sat.datapoint.com> from "Jack Taylor" at Oct 

22, 94 06:11:00 pm 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 726 


Also - the published doc, with the changes the committee requested should be 
avalible from the ARRL by request the first of the year. 


Cheers - greg 


According to Jack Taylor: 


effective for HF operations. 


Be advised a revision to the ax.25 standard is "in the works" and is 
currently before the ARRL futures committee for review. If anyone is 


authors, bbeech@huachuca-emh8.army.mil. 


73 de Jack 


VV VV VV VV VV VV NV 


From rmackay@bud.peinet.pe.ca Sat Oct 22 20:35:35 1994 

Return-Path: <rmackay@peinet.pe.ca> 

Received: from bud.peinet.pe.ca by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqyrqO-0000v5C; Sat, 22 Oct 94 20:35 CDT 

Received: by bud.peinet.pe.ca; id AA12970; Sat, 22 Oct 1994 22:35:27 -0300 

Date: Sat, 22 Oct 1994 22:35:26 -0300 (ADT) 

From: Ron Mackay <xrmackay@bud.peinet.pe.ca> 

Subject: Re: [HFSIG:36] Re: ALE 

To: hfsig@tapr.org 

In-Reply-To: <mOqypYA-0000vO0C@dptspd.sat.datapoint.com> 

Message-Id: <Pine.3.89.9410222257 .A12779-0100000@bud.peinet.pe.ca> 

Mime-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Sat, 22 Oct 1994, Jack Taylor wrote: 


effective for HF operations. 


Be advised a revision to the ax.25 standard is "in the works" and is 
currently before the ARRL futures committee for review. If anyone is 


authors, bbeech@huachuca-emh8.army.mil. 


73 de Jack 


VV VV VV VV VV VV 


Tried to get that file but "permission denied" instead for anonymous 
log-in at least. 


73 - Ron VE1AIC 


From barry@ia.net Sat Oct 22 20:55:07 1994 

Return-Path: <barry@ia.net> 

Received: from allanon.ia.net by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqys9G-0000aMC; Sat, 22 Oct 94 20:55 CDT 


Charles Brain suggests some changes could be made to ax.25 to make it more 


interested in looking over the proposed new ax.25 standard it is available 
via anonymous ftp from hereford.ampr.org /pub/hamradio/lapa.txt. If after 
review, comments wish to be made, they can be sent to one of the principle 


Charles Brain suggests some changes could be made to ax.25 to make it more 


interested in looking over the proposed new ax.25 standard it is available 
via anonymous ftp from hereford.ampr.org /pub/hamradio/lapa.txt. If after 
review, comments wish to be made, they can be sent to one of the principle 


Received: from localhost (barry@localhost) by allanon.ia.net (8.6.5/8.6.5) id 
UAAQ7692 for hfsig@tapr.org; Sat, 22 Oct 1994 20:54:40 -0500 

From: Barry Buelow - WAORJIT <barry@ia.net> 

Message-Id: <199410230154.UAAQ7692@allanon.ia.net> 

Subject: ASYNC vs Coherent 

To: hfsig@tapr.org 

Date: Sat, 22 Oct 1994 20:54:39 -0500 (CDT) 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 809 


I note that some of the comments on ALE refer to async. 


This thought hasn't been a part of the discussions yet but I thought 
it would be interesting before we all run off in one direction. 


I'm not directly involved with the design of GPS rcevrs, but they 

are getting _really_ small, low power and, most important, CHEAP. 
Street prices today are still a few hundred $. You can buy reasonable 
quantities of multi-channel units for in the range of $300 if you 

know where to look. 


This all leads to rather good frequency standards being possible in 
the not too distand future. Now being is phase lock is a little 
different issue, but real good frequency and timing are a start 

in the right direction. Knowing where and when to look for a signal 
is much different than just free running. 


73 Barry 
waOrjt 


From g4guo@dircon.co.uk Sun Oct 23 02:54:16 1994 
Return-Path: <g4guo@dircon.co.uk> 
Received: from tdc.dircon.co.uk by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqyxkr-Q001U£C; Sun, 23 Oct 94 02:54 CDT 
Received: from dircon.co.uk (tdc.dircon.co.uk) by tdce.dircon.co.uk with SMTP id 
AA11966 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Sun, 23 Oct 1994 08:52:24 +0100 
From: Charles Brain <g4guo@dircon.co.uk> 
Received: by dircon.co.uk (5.67b) id AA11958; Sun, 23 Oct 1994 08:52:22 +0100 
Date: Sun, 23 Oct 1994 08:52:22 +0100 
Message-Id: <199410230752.AA11958@dircon.co.uk> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:38] Re: LAPA 


Ron Mackay <rmackay@bud.peinet.pe.ca> writes: 
On Sat, 22 Oct 1994, Jack Taylor wrote: 


Tried to get that file but "permission denied" instead for anonymous 
log-in at least. 


VV VV VV 


73 - Ron VE1AIC 


Hi Ron and all, 
Yes I got the same thing! 


Regards Charles 
From g4guo@dircon.co.uk Sun Oct 23 02:54:23 1994 
Return-Path: <g4guo@dircon.co.uk> 
Received: from tdc.dircon.co.uk by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqyxkz-QO0O01U£C; Sun, 23 Oct 94 02:54 CDT 
Received: from dircon.co.uk (tdc.dircon.co.uk) by tde.dircon.co.uk with SMTP id 
AA11960 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Sun, 23 Oct 1994 08:52:23 +0100 
From: Charles Brain <g4guo@dircon.co.uk> 
Received: by dircon.co.uk (5.67b) id AA11954; Sun, 23 Oct 1994 08:52:17 +0100 
Date: Sun, 23 Oct 1994 08:52:17 +0100 
Message-Id: <199410230752.AA11954@dircon.co.uk> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:39] ASYNC vs Coherent 


Barry Buelow - WAORIT <barry@ia.net> writes: 
> I note that some of the comments on ALE refer to async. 


This thought hasn't been a part of the discussions yet but I thought 
it would be interesting before we all run off in one direction. 


VV VV 


Hello Barry, 


Certainly a synchronous system should reduce calling time on air. A small 

on air pool of calling frequencies could be used then after contact has been 
made a QSY to another frequency could be initiated to prevent blocking of the 
calling channels. 

Non synchronous "ALE" stations could call asynchronously. 


As we are not a military system we can rely on external time sources, in the 
UK we have a transmission on 60 KHz called MSF this is an atomic time standard 
you can buy a kit of parts to build a receiver for about $20. I guess WWV could 
be used in the U.S. While we wait for GPS to drop in price. 


The next problem is to channelise the HAM bands to allow easier handling in the 
database. 


Another big problem is the Radios themselves, when your rig reads say 14.070Mhz 
what frequency is it actually on. On SSB the dial frequency should be the 
frequency of the suppressed carrier. The other modes well I dont know. 

Also it would be nice to disable the input filtering or have solid state 
switching 
of the filters as when my TS850 scans I hear the relays clicking (and wearing 
out). 


Frequency stability is becoming a big issue especially on modes like CLOVER 
where you have to be within 10 or so Hz of the correct frequency and stay there. 


It would be nice if all modern radios had an external frequency reference input. 


Timeslots for sounding of stations would have to be arranged so as not to cause 
collisions. 


The modulation scheme during calling would need to be optimised for : 


1) Fast recognition. 

2) Robustness 

3) Easy to measure S/N, BER, MP etc. 

4) Measurement of path delay (this could be used to generate simple ionograms) 


A spin off of this of course would be a wonderful beacon system. 


All of this is perfectly possible with modern technology but I sometimes wonder 
if the guys using 5 watts and a hand key don't have the right idea. 

ALE systems are being developed to reduce the skills required of the operator 
and turn him into a simple communicator, operating is much of the fun of HAM 
radio. 


Bring back spark! 


Regards Charles 

From KY1TLuck@aol.com Sun Oct 23 09:46:37 1994 

Return-Path: <KY1TLuck@aol.com> 

Received: from mail02.prod.aol.net by dptspd.sat.datapoint.com with smtp 


(Smail3.1.28.1 #3) id mOqz4Bu-QQOQOQWFC; Sun, 23 Oct 94 09:46 CDT 


Received: by mail02.prod.aol.net 


(1.38.193.5/16.2) id AA24759; Sun, 23 Oct 1994 10:46:29 -0400 


Date: Sun, 23 Oct 1994 10:46:29 -0400 
From: KY1TLuck@aol.com 

Sender: KY1TLuck@aol.com 

Message-Id: <941023104625991923@aol.com> 


To: 


hfsig@tapr.org 


Subject: Official Observers 


I, for one, appreciate Greg's efforts at getting appropriate and detailed 
info regarding this particular 00/FCC matter out into the hands of those 
subscribed to this list. And I'm glad to see that ARRL HQ's Regulatory 
Information Branch continues to be so promptly responsive. This is good... 


I might be able to shed some light on a couple of other aspects of this 
matter, since it was I who was in charge of the ARRL/FCC Amateur Auxiliary 
(Official Observer) program for much of my 7 years at ARRL HQ. And having 
been an Official Observer Coordinator in the ARRL's volunteer Field 
Organization in two different ARRL Sections (Virginia and Eastern 


Massachusetts), I have an unusual perspective from both sides of the fence. 
I can understand, for example, why Fred Sober would be writing to FCC. And 
I can understand -- from the administrative side -- why that's a bad move on 
Fred's part. 


For one thing, it's absolutely forbidden. I know of no less than four 
Official Observers and two Official Observer Coordinators who were "removed" 
from their positions because of doing just that. The ARRL gets real jumpy 
when one of their troops makes contact with FCC, and this instance we're 
discussing right now is absolutely a PERFECT example of why that's so. 

Yah, I know; we all -- most of us anyway -- tend to think that word from 
Johnny Johnston is somehow that of God himself, FCC-wise. But there's two 
things to consider carefully: 


1. Johnny doesn't work for the enforcement part of FCC. In other words, 
while he may (and often does) express his opinion about certain Part 97 
regulations, they're just that, opinions. They're not binding. Only Part 97 
itself is. And let's get back to Part 97 in just a sec. 


2. I've personally witnessed the results of a VERY large number of inquiries 
from amateurs to FCC in the past decade. And I can assure you that, 
depending on who is telephoned, faxed, written to, pestered at a hamfest, or 
otherwise communicated with, the resulting opinions from FCC staff can -- and 
usually are -- remarkably different. This is clearly because of the way the 
question is posed, and it stands to reason that since we amateurs are 
typically very bad at communicating (sigh...) we're GOING to get differing 
opinions. 


I'm getting painfully wordy, so let me sum up. 


The whole issue is moot. Greg has already correctly put things in 
perspective; a packet bulletin is NOT, by ANY stretch of the imagination a 
one-way transmission. Transmissions from one TNC to another are two-way 
transmissions. Not one-way. Period. Thus, the supposed Notices of Apparent 
Liability that Fred Sober speaks of will never occur. And if OO notices 
happen, that's perfectly fine since they don't have the weight of Part 97 
enforcement anyway, except by way of friendly amateur-to-amateur peer 
pressure. 


I'd hate to guess how many whining phone calls I got every day for seven 
years from amateurs who'd gotten "picked on" by OO notices. My usual retort 
to them was "gee, have you considered throwing the post card in the trash and 
getting on with your amateur radio activities, OM?" "Well, (sputter, fume), 
but what are you gonna DO about this jerk who sent me the card, huh?" "well, 
I might drop him a note, congratulating him for continuing to express his 
opinions on what he believes would make the bands a better place to hang 


out". Which usually resulted in more sputtering and fuming, aimed at ME this 
time, which was probably better than having it aimed at the volunteer who was 
taking his best -- even if sometimes misguided -- shot. 


And, finally, let's all try to remember that this is a non-issue. NALS won't 
happen, and OO notices don't count, so let's move on. 


73 


Luck Hurder, KY1T *k KYITLUCK@AOL.COM xx 


Supporter of AMSAT, TAPR, and NARA 


From n7oo@huachuca-emh8.army.mil Sun Oct 23 11:08:15 1994 

Return-Path: <n7oo@huachuca-emh8.army.mil> 

Received: from huachuca-emh8.army.mil by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqz5St-0000d8C; Sun, 23 Oct 94 11:08 CDT 

Message-Id: <m0qz5St-0000d8C@dptspd.sat.datapoint.com> 


Date: Sun, 23 Oct 94 8:57:40 MST 
From: Jack Taylor <n7oo@huachuca-emh8.army.mil> 
To: hfsig@tapr.org 


Subject: Re: [HFSIG:40] Re: LAPA 


I'd forgotten that the lapa.txt file on hereford.ampr.org was a "working 

copy" of the proposed revised standard for ax.25 and not available for 

anonymous ftp. In view of Greg's comment that the ARRL will be releasing 

the document (presumably for comment) in the near future, probably best 

to wait for that one. That way will avoid confusion as everyone will be 

singing "from the same songbook". 

73 de Jack 

From barry@ia.net Sun Oct 23 12:46:24 1994 

Return-Path: <barry@ia.net> 

Received: from allanon.ia.net by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqz6ye-QQOQOHkC; Sun, 23 Oct 94 12:45 CDT 

Received: from localhost (barry@localhost) by allanon.ia.net (8.6.5/8.6.5) id 

MAA13394 for hfsig@tapr.org; Sun, 23 Oct 1994 12:10:07 -0500 

From: Barry Buelow - WAORJIT <barry@ia.net> 

Message-Id: <199410231710.MAA13394@allanon.ia.net> 

Subject: Re: [HFSIG:42] Official Observers 

To: hfsig@tapr.org 

Date: Sun, 23 Oct 1994 12:10:07 -0500 (CDT) 

In-Reply-To: <941023104625991923@aol.com> from "KY1TLuck@aol.com" at Oct 23, 94 

09:48:00 am 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 1169 


Luck, 


I appreciate your comments on the 00 and FCC. It is good to have 
someone with first hand experience comment. 


As you may recall, I threatened to petition the FCC on exactly 
this issue a few months ago. At the DCC in Mpls, I attempted 
to defend my position that bltns are one-way and therefore 
restricted to info bltns. 


The attitude of the sysops in the crowd was: 


1. ignorance of the rules - I expected better, but wasn't totally 
surprised. 


2. why bother - no one seems to see that there are NO values and 
any topic is acceptable for aa bltn. 


Obviously I was disappointed at being laughed off the stage. One 
major technical contributor to packet said "let the channels get jammed, 
then there will be a reason to go faster". 


The major problem I have with this entire episode is that it is one 
more reason that people with real brains will leave ham radio. The 
idiots are overrunning us and the liberals are letting them. 


It is very difficult to keep from screaming "dumb shit" into the 
microphone. 


If this is an indication of where ham radio is going, I'll go 
back to my model trains. 


73and thanks again for valuable insights, 


Barry waOrjt 


From gjones@tenet.edu Sun Oct 23 15:34:52 1994 

Return-Path: <gjones@tenet.edu> 

Received: from Kay-Abernathy.tenet.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqz9cw-Q000qdC; Sun, 23 Oct 94 15:34 CDT 

Received: (from gjones@localhost) by Kay-Abernathy.tenet.edu (8.6.9/8.6.9) id 

PAA16608 for hfsig@tapr.org; Sun, 23 Oct 1994 15:34:47 -0500 

From: Greg Jones <gjones@tenet.edu> 

Message-Id: <199410232034.PAA16608@Kay -Abernathy.tenet.edu> 

Subject: BBS Issue 

To: hfsig@tapr.org 

Date: Sun, 23 Oct 1994 15:34:47 -0500 (CDT) 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 425 


Hi Folks - would suggest we move the issue regarding the OO message 
concerning packet BBS messages be moved over to the BBSSIG mailing list, and 
let the HFSIG continue messages on the current topic.(i.e. simulators and 
more). 


By the way Johan - I think we can all agree that the current content of the 
HFSIG has been just great! Good Job. I really look forward to what the 
group will eventually produce. 


Cheers - Greg 
From barry@ia.net Sun Oct 23 21:35:05 1994 


Return-Path: <barry@ia.net> 
Received: from allanon.ia.net by dptspd.sat.datapoint.com with smtp 


(Smail3.1.28.1 #3) id mOqzFFV-QQ01UIC; Sun, 23 Oct 94 21:35 CDT 
Received: from localhost (barry@localhost) by allanon.ia.net (8.6.5/8.6.5) id 
VAAOQ2872 for hfsig@tapr.org; Sun, 23 Oct 1994 21:34:54 -0500 
From: Barry Buelow - WAORJIT <barry@ia.net> 
Message-Id: <199410240234.VAA02872@allanon.ia.net> 
Subject: sorry - wrong SIG 
To: hfsig@tapr.org 
Date: Sun, 23 Oct 1994 21:34:54 -0500 (CDT) 

X-Mailer: ELM [version 2.4 PL23] 
Content-Type: text 
Content-Length: 107 


Sorry group, 
I must have replied to the wrong msg from Luck. I'll try to be more 
careful. 


Barry waOrjt 


From muphaus@cris.com Mon Oct 24 00:41:38 1994 

Return-Path: <Muphaus@cris.com> 

Received: from cris.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqzIA2-Q001N6C; Mon, 24 Oct 94 00:41 CDT 

Received: from starcore.cris.com by cris.com [1-800-745-CRIS (voice) ] 

Received: by starcore.cris.com (4.1/SMI-4.1) 
id AAQ6646; Mon, 24 Oct 94 01:41:21 EDT 

To: hfsig@tapr.org 

From: muphaus@cris.com (Marv Uphaus) 

Subject: HFSIG on the Internet... 

Date: Sun, 23 Oct 1994 13:13:02 -0500 

Organization: CRIS via TELENET 

Reply-To: muphaus@cris.com 

Message-Id: <kUggkCysSYs8073yn@cris.com> 

In-Reply-To: <199410231710.MAA13394@allanon.ia.net> 

Lines: 21 


Barry wrote: 


>It is very difficult to keep from screaming “dumb shit" into the 
>microphone. 

> 

>If this is an indication of where ham radio is going, I'll go 
>back to my model trains. 


Barry and all...! This is the reason that all this TAPR HFSIG is being 
done on the Internet and not on a 40 meter digital net... I have been a 
ham for 39 years and I have seen it getting worse each year... It's the 
reason that a vast majority of the intelligent hams left ham radio and went 
to other endeavors, the technical ones to computers... So here we are on 
the Internet discussing HF radio... hi hi... 


Marv... K4BVG... 


-- Marv Uphaus -- muphaus@cris.com -- CompuServe: 72122,1253 -- 
-- PGP Public Key available in plan -- finger muphaus@cris.com_ -- 
-- U.S. Mail: 4031 Airport Blvd. #49 -- Mobile, AL 36608 USA_ -- 
-- Packet Radio: K4BVG @W4IAX.4#MOBAL.AL.USA.NA Ph: 205 343-9256 -- 
From wdubose@sacdm01.kelly.af.mil Mon Oct 24 08:55:03 1994 
Return-Path: <wdubose@sacdm01.kelly.af.mil> 
Received: from sacdm01.kelly.af.mil by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqzPrE-Q000dPC; Mon, 24 Oct 94 08:54 CDT 
Received: by sacdm01.kelly.af.mil (5.65b/1.0.2-rct) 
id AA28372; Mon, 24 Oct 94 08:46:09 -0500 
Message-Id: <9410241346 .AA28372@sacdm01.kelly.af.mil> 
Date: Mon, 24 Oct 94 08:45:58 -0500 
From: wdubose@sacdm01.kelly.af.mil (WALTER (WALT) D. DUBOSE - PKT) 
Subject: Re: [HFSIG:41] Re: ASYNC vs Coherent 
To: hfsig@tapr.org 
Reply-To: sat@sacdm01.kelly.af.mil, [D@sacdm01.kelly.af.mil, 
[D@sacdm01.kelly.af.mil, [Dk5yfw@sat.ampr.org 
X-Orig-Date: Sun, 23 Oct 94 02:56 CDT 
X-Orig-From: Charles Brain <g4guo@dircon.co.uk> 
X-Orig-Message-Id: <199410230752.AA11954@dircon.co.uk> 


In Charles message of 23 Oct 1994 at 0256 CDT, he writes: 
Barry Buelow - WAORIJT <barry@ia.net> writes: 
> I note that some of the comments on ALE refer to async. 


This thought hasn't been a part of the discussions yet but I thought 
it would be interesting before we all run off in one direction. 


VV VV VV 
VV VV 


Charles and All, 


Let me address some of these comments and then I'll go back to other 
messages and address some others (perhaps). 


I don't think the Harris, or Collins-Rockwell ALE units are concerned 
withe being Async or Sync...perhaps I'm missing a thought or two 
here. The Fredericks unit is made under license from Harris thus I 
would assume it is basically the same unit (cheaper parts? - cheaper 
labor?) . 


Hello Barry, 


Certainly a synchronous system should reduce calling time on air. A small 

on air pool of calling frequencies could be used then after contact has been 
made a QSY to another frequency could be initiated to prevent blocking of the 
calling channels. 

Non synchronous "ALE" stations could call asynchronously. 


VV VV VV VV 


I believe that this would be imperative...but how many? 5, 10? How 
wide a channel....5, 1, 1.5, 3 KHz? Who would decide where they 


would be located...hams (by agreement), the FCC in the states or 
other regulatory agency elsewhere or perhaps the IARU? This would 
require an accurate receiver and ALE signaling is *notx simply a 
short burst. 


For those not familiar with the signaling technique let me briefy 
describe the process in un-technical terms. 


1. The signal is a low baud rate robust signal...this could be made 
faster. 


2. Your receiver is "Scanning" all the ALE channels (yes...those 
frequencies xwould* channelize the ham bands) or only those for the 
mode you wished to use. You should be scanning at a specific rate and 
if you are scanning more than one band, you need a multi-band 
antenna...try this on for 40 & 20 meters. 


3. The signaling transmitter must transmit a query signal on 

one channel for a time equal to one complete scan cycle of all the 
possible channels. Then it moves to the next channel and repeats the 
process. 


Using only four frequencies (channels) in Saudi during the Desert 
Twins, it took more than two minutes (total cycle query time) to try 
and establish contact with a station if they never answered. 


Can you imagine what it would be like with 10 hams on 20 meters trying 
to make an ALE connect on just four voice calling frequencies. -x*Andx 
this does not consider what would happen if someone decided to have a 
QSO on the ALE channel or simply was coordinating a move to a working 
frequency. You xwould* have to have DSP or sylabic (correct my 
spelling if incorrect) squelch to keep from steping on a QSO. All of 
this assumes that you don't have a hidden transmitter...then the 
matter really gets stickey. 


Calling frequencies in the U.S. have never been used as calling 
frequencies but rather "gathering" channels. How has this worked in 
other countries/parts of the world? Has it worked any better? 
Perhaps we in the U.S. are just not as regimented. 


> 

> As we are not a military system we can rely on external time sources, in the 

> UK we have a transmission on 60 KHz called MSF this is an atomic time standard 
> you can buy a kit of parts to build a receiver for about $20. I guess WWV could 
> be used in the U.S. While we wait for GPS to drop in price. 


Why not include a seperate receiver in the ALE equipment if this is 
needed. 


> 
> The next problem is to channelise the HAM bands to allow easier handling in the 
> database. 


Good luck on the HF bands. See above. 


Another big problem is the Radios themselves, when your rig reads say 14.070Mhz 
what frequency is it actually on. On SSB the dial frequency should be the 
frequency of the suppressed carrier. The other modes well I dont know. 

Also it would be nice to disable the input filtering or have solid state 
switching 
> of the filters as when my TS850 scans I hear the relays clicking (and wearing 
out) . 


VVVNV Vv 


Ah yes...you *WILL* (yes I screamed) need 10 Hz resolution and accuracy and 
no drift and let me tell you as chief of communications maintenance 

for the militray using the latest state-of-the-are equipment, maintaing 

an accurate 10 Hz resolution drift free transceiver is *xnot*x easy and 

the equipment is xexpensivex. Tho, software might make this easier, 

you would need software that was "rig" specific and assuming all rigs 

could be tuned by software/hardware. 


> Frequency stability is becoming a big issue especially on modes like 
> CLOVER where you have to be within 10 or so Hz of the correct 
> frequency and stay there. 


See Above. 


> It would be nice if all modern radios had an external frequency 
> reference input. 


This isn't really needed if the units frequency standard is accurate. 
> Timeslots for sounding of stations would have to be arranged so as not to cause 
> collisions. 


Rgr Rgr...see above 


> The modulation scheme during calling would need to be optimised for : 

> 1) Fast recognition. 

> 2) Robustness 

> 3) Easy to measure S/N, BER, MP etc. 

> 4) Measurement of path delay (this could be used to generate simple ionograms) 
> 

> A spin off of this of course would be a wonderful beacon system. 


I think this is a better solution...a world-wide systems of beacons 
to automatically determine band is best with hardware and 
software in the users transceiver...making it passive. 


All this assumes reciprocity. 


VV VV WV 


All of this is perfectly possible with modern technology but I 
sometimes wonder if the guys using 5 watts and a hand key don't have 
the right idea. ALE systems are being developed to reduce the 
skills required of the operator and turn him into a simple 
communicator, operating is much of the fun of HAM radio. 


Bring back spark! 


Well, I wouldn't go that far...but basic CW is the basic digital mode. 


73, Walt/K5YFW@work 

From wdubose@sacdm01.kelly.af.mil Mon Oct 24 09:24:42 1994 

Return-Path: <wdubose@sacdm01.kelly.af.mil> 

Received: from sacdm01.kelly.af.mil by dptspd.sat.datapoint.com with smtp 


(Smail3.1.28.1 #3) id mOqzQK8-Q001ULC; Mon, 24 Oct 94 09:24 CDT 


Received: by sacdm01.kelly.af.mil (5.65b/1.0.2-rct) 


id AA29710; Mon, 24 Oct 94 09:16:08 -0500 


Message-Id: <9410241416.AA29710@sacdm01.kelly.af£.mil> 

Date: Mon, 24 Oct 94 09:16:06 -0500 

From: wdubose@sacdm01.kelly.af.mil (WALTER (WALT) D. DUBOSE - PKT) 
Subject: Re: [HFSIG:35] Re: ALE 


To: 


hfsig@tapr.org 


Reply-To: k5yfw@sat.ampr.org 


X- 
X- 
X- 


Orig-Date: Sat, 22 Oct 94 12:04 CDT 
Orig-From: Charles Brain <g4guo@dircon.co.uk> 
Orig-Message-Id: <199410221657 . AAO4088@dircon.co.uk> 


Again, Greetings. 


In Charles message of 22 Oct 1994 at 1204 CDT, he writes: 


> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 


k5yfwe@k5yfw.ampr.org (Walter D. DuBose - K5YFW) writes: 
> Greetings Charles and All, 


If on any of those channels there was a 

voice or data QSO going on, it would place its signaling tone on 
the frequency it did not recognize it and "stepped" on the QSO. 
If critical AE data was being passed, it had to be 
re-transmitted. It really had a way of ruining a QSO as the 
signaling took many seconds of transmission time on each 
frequency to establish a connection. 


VV VV VV 


Hi Walter, 

0.K I understand about the problem, The fredricks ALE controller has 

a voice detect function, however as they are only using a TMS320C10 

I guess it is not very effective. As you say this is a problem. I have 
seen an intelligent squelch that uses a DSP in conjunction with a neural 
net to recognise speech on a channel, it takes a few hours to train though. 
Possibly some form of pilot tone SSB would be more suitable. Or the ALE 
could send a "Is the channel free call" I guess there are a lot of diffent 
things that could be done. 


think a sylabelic (check/correct my spelling) squelch such as 


Kenwood has on one/some of their Marine HF rigs would be all that is 
needed...perhaps a little more but I don't think a lot of DSP is 
needed here...perhaps all the voice/data recognitation could be in 
one small chip. 


As far as Chelmsford is concerned no I am not a member although I have 
been to the club a couple of times and I am friendly with one of the 
committe members. I will pass on your greetings. 

By the way I work at Mr Guglielmo's Wireless Works in Chelmsford. 


VVVV Vv 


For others, I sent a message to Charles referencing my wonderful visit 
to the UK several years ago and my visit with the Chelmsford ARC. If 
you ever have an opportunity to visit the UK, have tea (morning, 
afternoon, anytime) with the UK hams. They a most wonderful lot. 
Charles works for the Macaroni Radio Works in Chelmsford...a enormous 
plant with all sorts of antennae (see Charles, I can spell some things 
correctly) sticking up all over the place. 


As far as packet is concerned I wonder if it would be possible to 

use a DSP based channel conditioner using the HDLC flags as a training 
sequence to reduce the multi-path problems. Also if a data frame has to be 
sent many times it may be possible to store multiple copies of the frame and 
do a majority vote on the data. It should be possible to do this without 

a change in the protocol. There is probably some flaw in my idea. 


VV VV VV 


This is for programmers and technical types...please take note. 


I do think an improved packet protocol for HF is needed, I know a 
lot of people are thinking about the problem. I would favour a 
waveform similar to CLOVER i.e using a small number of tones to 
reduce baud rate and a priority ack protocol. 


VVV WV 


Phil Karn is working on a replacement to AX.25...perhaps his input is 
needed here. 


I don't think we want to mix a transmission protocol with a modem 
protocol...I've never been comfortable with the layered structure so 
I don't use it...please excuse this little quirk. 


I refer to CLOVER as a modem and transmission protocol. I like to 
keep them seperate...this is a personal thing so just humor me. 

While AX.25 may/could use improvement/change/replecement, I'd rather 
focus on the modem protocol just a bit. The Bell 103 standard is a 
modem protocol...CLOVER's four parallel tones is a modem protocol, 
MIL-STD-188-110c (U.S. DoD) 39 parallel tone modem is a modem 
protocol. Perhaps we first need to create a modem protocol/modem to 
pulg onto existing transmission protocols...AMTOR, RTTY/ASCII, AX.25, 
G-TOR, Pactor. Later adding the transmission protocol. 


However, for the programmers, it may be easier to do both. 


> As far as the English is concerned, my computer speaks Colonial 
> English, anyway my father came from the Canadian Colony so I can 
> just about understand you lot!! 


73, Walt/K5YFW@work 
From FORRERJ@frl.orst.edu Mon Oct 24 12:02:36 1994 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqzSn3-OQ000sAC; Mon, 24 Oct 94 12:02 CDT 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id CAAQ7589 for <hfsig@tapr.org>; Mon, 24 Oct 1994 
02:41:43 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Mon, 24 Oct 94 10:02:24 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 24 Oct 94 10:02:01 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Mon, 24 Oct 1994 10:01:55 PST8PDT 
Subject: Re: [HFSIG:39] ASYNC vs Coherent 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <5F8C9AD7E20@fr1.orst.edu> 
Hi Barry 


You have a good point here - if we were to lay the groundwork for a new 
system, a synchronous approach would probably have definate 

advantages. (note that synchronous refers to synchronous detection methods - 
there also is synchronous symbol detection, that is something different). 


In this regard: from what I gather, a GPS receiver would be an ideal 
component in a SS system. Are there any provisions for us doing direct 
sequence SS on HF? What would it take - STA? If we can resolve the details 
on resolving full monitoring capabilities of amateur radio SS on HF (which 
I believe is possible), this may be the answer to our problems. 


Am I just day dreaming, or would it be possible to build a 
RF spreading/despeading subsystem, say taking a 3 Khz voice channel and 
utilizing a slot, say 14.000 - 14.200 Mhz? 


73's Johan 


From FORRERJ@frl.orst.edu Mon Oct 24 12:14:46 1994 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqzSxT-QQO0OqMC; Mon, 24 Oct 94 12:13 CDT 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id CAA0Q7374 for <hfsig@tapr.org>; Mon, 24 Oct 1994 
@2:15:55 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Mon, 24 Oct 94 9:36:37 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 24 Oct 94 9:36:26 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Mon, 24 Oct 1994 09:36:24 PST8PDT 
Subject: Re: [HFSIG:49] Re: ALE 

Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <5F85C821A8E@frl.orst.edu> 

Hi folks, 

Wow - I'm pleased to see all the activity. Good stuff! 
A few points to respond to: 


Sound card details: 


The sound card that I'm using contains an Analog Devices ADSP-2115 DSP chip 
as well as the standard Windows sound chip, the AD1848. The architecture 
for this low cost board was developed by Analog Devices and named 

the "Personal Sound Architecture" (PSA). Several companies uses this 

chip set on their sound cards, i.e., Cardinal Pro 16 (plus), Orchid 
Soundwave 32, Western Digital, Adaptec, Wearnes Beethoven, Echo Speech. 
There may be others too. 


As far as compatibility is concerned, their digital interface are all the 
same, however, there are some differences in audio circuitry. I have some 
experience with the Cardinal and the Orchid Soundwave 32. They both work 
just fine for DSP dev. work, though are second rate sound cards if that is 
what you are looking for. I bought the Orchid product because it uses the 
latest and fastest revision of the ADSP-2115 DSP chip, i.e., 20 Mhz vs. the 
16 Mhz in the others. The Cardinal Pro 16 is available as low as $80 from 
PC Connection - I paid in the $160 range for the Orchid card. 


As far as DSP software is concerned - I wrote two articles (and Jon 

Bloom and the QEX editorial staff did a great job to make the materials look 
very professional) about this card: The August 1994 issue deals 

with the hardware registers and how to program it using a free software 
toolkit - the second one will appear in the upcoming (November 1994) QEX. 


It shows the implementation of an adaptive 100/200 baud DSP HF modem. I 
think Marv will enjoy that one as it will answer most of his questions. 


The PSA architecture was designed with the upcoming Windows 95 (Chicago) 
DSP API in mind - In the mean time, Analog Devices are giving away free SDK 
for using this card doing DSP development work under Windows. I have 
written a few programs using this platform - however, it requires yet 
another layer of programming and further knowledge of yet another 
programming philosophy to get even something simple working. It 

does work reasonably well. I do believe, however, that for our purposes, we 
would need to stick to writing in assembly and DOS (for a while at least). 


Other software that I have available for these PSA cards: 


* PSATOR - AMTOR for the PSA cards (RTTY/ASCII will be added in future) 

* PSA-Pactor - Pactor for PSA cards. This is a full rx/tx implementation 
using the adaptive modems mentioned above. It also implements 
full 16-bit memory ARQ in conjunction with brute force search 
algorithms. A 386/25 or better computer is required. 

* LMS noise reduction - A port of the W9GR code. 


These are shareware and I have attempted to keep the UCSD ftp site up to 
date. However, I will provide copies if you could be so kind to send me a 
formatted disk and SASE/mailer. 


I hope this brief reply answers the questions on hardware / software for the 
sound card. There are further software tools available, but I dont want to 
waste further bandwidth on that for the moment. 


HF Channel simulator 


Lets wait till we have had a chance to study the materials. I think Jon and 
Hugh both indicated interest in implementation details, so I am sure that 
we can start exchanging ideas about that shortly. 


ALE performance 


I think I understand that the present implementation of ALE has both a 
routing function as well as a messaging structure. What interest me about 
this protocol, is its modulation scheme - it uses 8-ary FSK and Golay 
(24,12) coding. It would be relatively easy to implement for amateur 
radio application - just a thought: perhaps replacing 300 baud 

packet? 


The future of AX.25 


Although it may be a while until we progress to the data link layer, I do 


think it would be wise if we pay some attention to these efforts. Please 
keep us posted on what is happening - thanks. 


73's 


Johan 


From g4guo@dircon.co.uk Mon Oct 24 13:57:57 1994 
Return-Path: <g4guo@dircon.co.uk> 
Received: from tdc.dircon.co.uk by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOQqzUag-Q001BLC; Mon, 24 Oct 94 13:57 CDT 
Received: from dircon.co.uk (tdc.dircon.co.uk) by tde.dircon.co.uk with SMTP id 
AA06299 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Mon, 24 Oct 1994 18:54:49 GMT 
From: Charles Brain <g4guo@dircon.co.uk> 
Received: by dircon.co.uk (5.67b) id AAQ6286; Mon, 24 Oct 1994 18:54:42 GMT 
Date: Mon, 24 Oct 1994 18:54:42 GMT 
Message-Id: <199410241854 .AA06286@dircon.co.uk> 
To: hfsig@tapr.org 
Subject: Re: TENTATIVE PROJECT OUTLINE 


"Johan Forrer 
FL" <FORRERJ@frl.orst.edu> writes: 
Hi All, 


> 
> 
> 
> I trust that you have had an opportunity to look at the modulation 
> schemes in Table 1. of my last posting. I thought it would be of 

> interest to provide further outlines of those ideas and get some 

> discussion and interaction started. Please be so kind and take a 

> few moments to study the summary given below. 

> 

> 

> 

> 

> 


Remember, the HFSIG can handle multiple active treads, however, 
please be sure to use an appropriate "subject" when you post your 
replies. This way we will know what your message is about. 


Hello Johan et al, 


I joined the net after you posted this could you email it to me or 
re-post it please. 


I was thinking if we use these modems in the rtty sections of the band 
we have a shroud idea of the QRM we are going to see. 


1) 170Hz FSK 
2) 200Hz FSK 
3) CW 

4) 4 tone ALE 


5) Ourselves! 


Regards Charles. 
From g4guo@dircon.co.uk Mon Oct 24 13:58:10 1994 
Return-Path: <g4guo@dircon.co.uk> 
Received: from tdc.dircon.co.uk by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqzUas-Q001BLC; Mon, 24 Oct 94 13:58 CDT 
Received: from dircon.co.uk (tdc.dircon.co.uk) by tde.dircon.co.uk with SMTP id 
AA06290 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Mon, 24 Oct 1994 18:54:44 GMT 
From: Charles Brain <g4guo@dircon.co.uk> 
Received: by dircon.co.uk (5.67b) id AAQ6273; Mon, 24 Oct 1994 18:54:37 GMT 
Date: Mon, 24 Oct 1994 18:54:37 GMT 
Message-Id: <199410241854 .AA06273@dircon.co.uk> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:48] Re: ASYNC vs Coherent 


wdubose@sacdm01.kelly.af.mil (WALTER (WALT) D. DUBOSE - PKT) writes: 
In Charles message of 23 Oct 1994 at 0256 CDT, he writes: 
Barry Buelow - WAORIJT <barry@ia.net> writes: 


> I note that some of the comments on ALE refer to async. 


This thought hasn't been a part of the discussions yet but I thought 
it would be interesting before we all run off in one direction. 


VV VV VV 
VV VV 


Charles and All, 


Let me address some of these comments and then I'll go back to other 
messages and address some others (perhaps). 


I don't think the Harris, or Collins-Rockwell ALE units are concerned 
withe being Async or Sync...perhaps I'm missing a thought or two 
here. The Fredericks unit is made under license from Harris thus I 
would assume it is basically the same unit (cheaper parts? - cheaper 
labor?) . 


VVVV VV VV VV VV VV VV VV VV WV 


Hi Walt, 

The sync part I was refering to was at call setup. All stations in 
the net that are able to scan are listening on the same channel at any 
time. This means there is no scanning section to the call. An originating 
station can estimate the best channel tune and wait, at the right moment 
when everyone is listening it makes the call. This also means that everyone 
is listening at the most likely time to hear someone else. 

Net synchronisation is vital, in an amateur environment an external sync 
source can be used i.e GPS. In a military environment the network has to 
self sync. Normaly this consists of starting in async operation, when one 
hears a more senior node in the net that has sync you sync to him etc. 

However when the net starts to get busy performance drops off dramatically. 
Sync systems normally have abot 100 channels in the scan group, also every few 


minutes a new set of 100 channels are allocated. I have a paper written by 
a Prof Carlson in Sweden on this topic. 


Regards Charles. 
From g4guo@dircon.co.uk Mon Oct 24 14:07:12 1994 
Return-Path: <g4guo@dircon.co.uk> 
Received: from tdc.dircon.co.uk by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqzUjY-QQOQOMCC; Mon, 24 Oct 94 14:07 CDT 
Received: from dircon.co.uk (tdc.dircon.co.uk) by tde.dircon.co.uk with SMTP id 
AA08208 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Mon, 24 Oct 1994 19:04:26 GMT 
From: Charles Brain <g4guo@dircon.co.uk> 
Received: by dircon.co.uk (5.67b) id AAQ8195; Mon, 24 Oct 1994 19:04:23 GMT 
Date: Mon, 24 Oct 1994 19:04:23 GMT 
Message-Id: <199410241904.AA08195@dircon.co.uk> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:51] Re: ALE 


"Johan Forrer 

FL" <FORRERJ@frl.orst.edu> writes: 
> ALE performance 

> daa ie as a ce pla 


I think I understand that the present implementation of ALE has both a 
routing function as well as a messaging structure. What interest me about 
this protocol, is its modulation scheme - it uses 8-ary FSK and Golay 
(24,12) coding. It would be relatively easy to implement for amateur 
radio application - just a thought: perhaps replacing 300 baud 

packet? 


VV VV VV MV 


Hello again, 


It needs tidying up but I have written some C code that does GOLAY (24,12) 
as per the MIL STD encoding and decoding. It uses a look-up table to do 
the encoding and also another look up that takes the error syndrome and 
finds the error vector which you XOR with the original data, it also tells 
you how many errors it has detected so you can either correct or detect. 

It seems to work i.e it corrects errors 0.K. I used the Parity matrix in 
the standard. 


Regards Charles 

From gjones@tenet.edu Mon Oct 24 14:33:30 1994 

Return-Path: <gjones@tenet.edu> 

Received: from Kay-Abernathy.tenet.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqzV93-0000zWC; Mon, 24 Oct 94 14:33 CDT 

Received: (from gjones@localhost) by Kay-Abernathy.tenet.edu (8.6.9/8.6.9) id 

0AA22723 for hfsig@tapr.org; Mon, 24 Oct 1994 14:33:23 -0500 

From: Greg Jones <gjones@tenet.edu> 

Message-Id: <199410241933 .0AA22723@Kay -Abernathy.tenet.edu> 

Subject: Re: [HFSIG:52] Re: TENTATIVE PROJECT OUTLINE 

To: hfsig@tapr.org 

Date: Mon, 24 Oct 1994 14:33:19 -0500 (CDT) 

In-Reply-To: <199410241854.AAQ6286@dircon.co.uk> from "Charles Brain" at Oct 24, 


94 02:04:00 pm 

X-Mailer: ELM [version 2.4 PL23] 
Content-Type: text 
Content-Length: 2045 


Just as a reminder, all messages from any of the TAPR SIGs are available by 
month from the listserv. 


Simply send a message to listserv@tapr.org and in the message body state 
‘index -all' or in this case ‘index hfsig’. 


This will then get you a listing of the files that can be requested. 
The command for that is: 
get area filename 


Example: 
get tapr taprinfo.txt 


This would get you the file taprinfo.txt in the area tapr. When you do the 
index, you will see that the files you want are in an area, so when you do 
the get, just fillin the area and filename. 


This way, anyone can review the entire SIG from the start. 


Cheers - Greg 


TAPR Office (817) 383-0000 | Internet: gjones@tenet.edu 


According to Charles Brain: 

> 

> "Johan Forrer 

FL" <FORRERJ@frl.orst.edu> writes: 
> > Hi All, 


I trust that you have had an opportunity to look at the modulation 
schemes in Table 1. of my last posting. I thought it would be of 
interest to provide further outlines of those ideas and get some 
discussion and interaction started. Please be so kind and take a 
few moments to study the summary given below. 


Remember, the HFSIG can handle multiple active treads, however, 
please be sure to use an appropriate "subject" when you post your 
replies. This way we will know what your message is about. 


VV VV VV VV VV VV OV 
VVVV VV VV VV VV 


Hello Johan et al, 


I joined the net after you posted this could you email it to me or 
re-post it please. 


I was thinking if we use these modems in the rtty sections of the band 
we have a shroud idea of the QRM we are going to see. 


1) 170Hz FSK 
2) 200Hz FSK 
3) CW 

4) 4 tone ALE 
5) Ourselves! 


Regards Charles. 


VV VV VV VV VV VV VV WV 


From wdubose@sacdm01.kelly.af.mil Mon Oct 24 14:45:53 1994 
Return-Path: <wdubose@sacdm01.kelly.af.mil> 
Received: from sacdm01.kelly.af.mil by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqzVKt-QQOQOVFC; Mon, 24 Oct 94 14:45 CDT 
Received: by sacdm01.kelly.af.mil (5.65b/1.0.2-rct) 
id AAQ7884; Mon, 24 Oct 94 14:37:13 -0500 
Message-Id: <9410241937 .AAQ7884@sacdm01.kelly.af.mil> 
Date: Mon, 24 Oct 94 14:37:11 -0500 
From: wdubose@sacdm01.kelly.af.mil (WALTER (WALT) D. DUBOSE - PKT) 
Subject: Re: [HFSIG:53] Re: ASYNC vs Coherent 
To: hfsig@tapr.org 
Reply-To: k5yfw@sat.ampr.org 
X-Orig-Date: Mon, 24 Oct 94 14:04 CDT 
X-Orig-From: Charles Brain <g4guo@dircon.co.uk> 
X-Orig-Message-Id: <199410241854 .AAQ6273@dircon.co.uk> 


Charles, 


In your message of 24 Oct 1994 at 1404 CDT, you write: 
wdubose@sacdm01.kelly.af.mil (WALTER (WALT) D. DUBOSE - PKT) writes: 
Charles and All, 


Let me address some of these comments and then I'll go back to other 
messages and address some others (perhaps). 


I don't think the Harris, or Collins-Rockwell ALE units are concerned 
withe being Async or Sync...perhaps I'm missing a thought or two 
here. The Fredericks unit is made under license from Harris thus I 
would assume it is basically the same unit (cheaper parts? - cheaper 
labor?) . 


VV VVVV VV VV MV 


Hi Walt, 

The sync part I was refering to was at call setup. All stations in 
the net that are able to scan are listening on the same channel at any 
time. This means there is no scanning section to the call. An originating 
station can estimate the best channel tune and wait, at the right moment 


VV VV VV VV VV VV VV VV VV 


> when everyone is listening it makes the call. This also means that everyone 

> is listening at the most likely time to hear someone else. 

> Net synchronisation is vital, in an amateur environment an external sync 

> source can be used i.e GPS. In a military environment the network has to 

> self sync. Normaly this consists of starting in async operation, when one 

> hears a more senior node in the net that has sync you sync to him etc. 

> However when the net starts to get busy performance drops off dramatically. 

> Sync systems normally have abot 100 channels in the scan group, also every few 
> minutes a new set of 100 channels are allocated. I have a paper written by 

> a Prof Carlson in Sweden on this topic. 


I'd really hate to tie my HF operation to the presence of a satellite... 
If I'm going to do that, I might as well get a nitch on a geosync 

bird and send 19.2 data and to heck with HF. Besides will I now have 
to have two receivers, coax and antennas just to work HF. And too, 

my truck is already filled with radio equipment and antennas..I will 
now need another "rig" and antenna on/in the truck and will have to 
park in the hot sun to work HF...not under a cool shade tree cause I 
gotta receive the satellite. 


The reason many U.S. military units use HF is they don't want to 
depend on a satellite...their xtoo easy*x to knock out. 


Realizing that GPS boxes are and will come down in price, and I'll 
need another box for the ALE, I'll soon have a bunch of money in 
equipment. 


If we don't watch out, an HF rig will cost 2000 PS. 
I might add...where's the KISS? 


Walt/K5YFW 

From barry@ia.net Mon Oct 24 22:53:48 1994 

Return-Path: <barry@ia.net> 

Received: from allanon.ia.net by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOqzcxD-Q001S0C; Mon, 24 Oct 94 22:53 CDT 

Received: from localhost (barry@localhost) by allanon.ia.net (8.6.5/8.6.5) id 

WAA12461 for hfsig@tapr.org; Mon, 24 Oct 1994 22:53:37 -0500 

From: Barry Buelow - WAORIT <barry@ia.net> 

Message-Id: <199410250353 .WAA12461@allanon.ia.net> 

Subject: Re: [HFSIG:50] Re: ASYNC vs Coherent 

To: hfsig@tapr.org 

Date: Mon, 24 Oct 1994 22:53:36 -0500 (CDT) 

In-Reply-To: <5F8C9AD7E20@frl.orst.edu> from "Johan Forrer 

FL" at Oct 24, 94 12:06:00 pm 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 1841 


> 
> Hi Barry 
> 


You have a good point here - if we were to lay the groundwork for a new 
system, a synchronous approach would probably have definate 

advantages. (note that synchronous refers to synchronous detection methods - 
there also is synchronous symbol detection, that is something different). 


VVV WV 


exactly what I was thinking. tx and rx in at least freq sync and possibly 
in phase sync. 


In this regard: from what I gather, a GPS receiver would be an ideal 
component in a SS system. Are there any provisions for us doing direct 
sequence SS on HF? What would it take - STA? If we can resolve the details 
on resolving full monitoring capabilities of amateur radio SS on HF (which 
I believe is possible), this may be the answer to our problems. 


VVVVV VV 


It seems to me that any serious improvement is hf throughput is not 
going to come from an inexpensive chrome box that plugs in to the mic 
and speaker jacks. 


There is a cascading effect. Good throughput requires good freq/time 
stability. 99.99% of off the shelf rigs do NOT support external freq 
references. 


Without addressing SS for now, this leads to a total system design: 
timebase, tx, rx, modem. Consider that a good system out to be 
something in the 50 to 100W range, and doesn't need all the chrome 
and knobs of typical modern radios, single band or a couple of bands, 
what else? 


This is a rather substantial design task, but it brings all the important 
technical issues into play. Major flexibility of operation issues are 
not a design requirement. 


If this system cost $1000, it would be a huge bargain. 


Am I just day dreaming, or would it be possible to build a 
RF spreading/despeading subsystem, say taking a 3 Khz voice channel and 
utilizing a slot, say 14.000 - 14.200 Mhz? 


> 
> 
> 
> 
> 73's Johan 
> 

J 


ust dreaming along... 


73 Barry 


From shane@mdd.comm.mot.com Tue Oct 25 23:35:15 1994 

Return-Path: <shane@mdd.comm.mot.com> 

Received: from motgate.mot.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOr004t-O0000uPC; Tue, 25 Oct 94 23:35 CDT 

Received: from mothost.mot.com ([129.188.137.101]) by motgate.mot.com with SMTP 

(5.67b/IDA-1.4.4/MOT-3.1 for <hfsig@tapr.org>) 


id AA25218; Tue, 25 Oct 1994 20:24:26 -0500 
Received: from mdd.comm.mot.com (mdisea.mdd.comm.mot.com) by mothost.mot.com with 
SMTP (5.67b/IDA-1.4.4/MOT-3.1 for <hfsig@tapr.org>) 
id AA15114; Tue, 25 Oct 1994 12:31:36 -0500 
Received: from daffyduck.mdd.comm.mot.com by mdd.comm.mot.com (4.1/SMI-4.1) 
id AAQ2407; Tue, 25 Oct 94 10:03:33 PDT 
Received: by daffyduck.mdd.comm.mot.com (4.1/SMI-4.1) 
id AA19089; Tue, 25 Oct 94 10:03:31 PDT 
Date: Tue, 25 Oct 1994 10:03:26 -0700 (PDT) 
From: Hugh Shane <shane@mdd.comm.mot.com> 
X-Sender: shane@daffyduck 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:51] Re: PSA 
In-Reply-To: <5F85C821A8E@fr1.orst.edu> 
Message-Id: <Pine.SUN.3.90.941025091408 .15133A-100000@daffyduck> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Mon, 24 Oct 1994, Johan Forrer FL wrote: 


As far as compatibility is concerned, their digital interface are all the 
same, however, there are some differences in audio circuitry. I have some 
experience with the Cardinal and the Orchid Soundwave 32. They both work 

just fine for DSP dev. work, though are second rate sound cards if that is 
what you are looking for. I bought the Orchid product because it uses the 


VVVV VV 


Is the audio interface on these cards sufficient for digital communication? 


The PSA architecture was designed with the upcoming Windows 95 (Chicago) 
DSP API in mind - In the mean time, Analog Devices are giving away free SDK 
for using this card doing DSP development work under Windows. I have 
written a few programs using this platform - however, it requires yet 
another layer of programming and further knowledge of yet another 
programming philosophy to get even something simple working. It 

does work reasonably well. I do believe, however, that for our purposes, we 
would need to stick to writing in assembly and DOS (for a while at least). 


VV VV VV VV VV 


How about Linux? With it's multitasking capabilities, Linux is an excellent 
platform for packet. And, of course, for software development you can't 
beat Unix. All we need are Linux driver for the Personal Sound 

Architecture and Unix-hosted development tools. 


> Other software that I have available for these PSA cards: 


> 

> * PSATOR - AMTOR for the PSA cards (RTTY/ASCII will be added in future) 
> * PSA-Pactor - Pactor for PSA cards. This is a full rx/tx implementation 

> using the adaptive modems mentioned above. It also implements 


> full 16-bit memory ARQ in conjunction with brute force search 


> algorithms. A 386/25 or better computer is required. 
> x LMS noise reduction - A port of the W9GR code. 


How about K9NG/G3RUH modulation? (I'm also putting together a node for our 
local VHF TCP/IP network. ) 


73 
Hugh 
From FORRERJ@frl.orst.edu Wed Oct 26 10:38:09 1994 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOrOAQQ-00015nC; Wed, 26 Oct 94 10:38 CDT 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id BAA18116 for <hfsig@tapr.org>; Wed, 26 Oct 1994 
01:17:10 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Wed, 26 Oct 94 8:37:56 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 26 Oct 94 8:37:40 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERIJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Wed, 26 Oct 1994 08:37:40 PST8PDT 
Subject: Re: [HFSIG:58] Re: PSA 

Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <62763272701@frl.orst.edu> 
Hugh, 


My experiences with the audio of the sound card tells me that its 

more than adequate for our usage. The modems that I have played with 

only runs at a minimal sampling rate of 5.5125 kHz and I have found 

the anti-aliasing/recon filters very effective to be able to run at that 
low sample rate. The LMS noise reducer runs at about 19 kHz and the audio 
quality is quite good, if not better than the commercial boxes doing the 
same thing. The only thing that the card does not have is digital I/0. 
However, someone with a bit of ingenuity can fabricate a "port". I use a 
serial port on the host for that purpose in the interim. 


Tom, HB9INX has written 1200 and 9600 baud packet modems for the card - I 
have no further details except knowing of its exsistance. I do know, 
however, that he told me that he built a direct interface to the DSP's 
"SPORT" for data I/0. So - it can be done. Tom has been very quiet 

lately, so I dont know the status of that project of his. It would be real 
nice if we can make a 9600/G3RUH modem available for the card. Perhaps you 
should be the one do it? 


I hope to post a summary on materials that I have been working on regarding 
modulation schemes and possible ways of debugging/evaluating the system, 
by monday. 


Please give your thoughts on your DSP platform high priority - the learning 
curve is real steep and we will be starting to do some real stuff in the 
very near future. Let me assure you - there is a lot of fun ahead! 


Hope I addressed all the questions. 
73's 
Johan 


From FORRERIJ@frl.orst.edu Wed Oct 26 10:52:24 1994 
Return-Path: <FORRERJ@frl.orst.edu> 
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Wed, 26 Oct 94 8:52:17 PST8PDT 
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PST8PDT 
From: "Johan Forrer 
FL" <FORRERIJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Wed, 26 Oct 1994 08:52:11 PST8PDT 
Subject: Re: [HFSIG:58] Re: PSA 

Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <627A1243BB7@frl.orst.edu> 
Hugh, 


About Linux - I have a system that is used for experimentation. And I do 
think that it has tremendous capabilities, unfortunately, however, it is a 
very fast moving target and I have found myself maintaining the OS more 
than doing any exiting DSP development work. A DSP platform for Linux will 
probably require a kernel hack similar to the AX.25 project for Linux - You 
really have to know what you are doing. I do believe that one could 
probably put something really nice together. 


On the other hand - if you are interested in wider audience, Linux is 
somewhat out on a limb. There really is only one fellow doing the sound 
drivers (and he has quit doing that), and from what I gathered, it is quite 
generic - a far cry from trying to actually run your own DSP code on your 
sound card. On the other side of the coin, with the battle going on between 
the Microsoft and 0S/2 worlds, something useful may emerge. In following the 
DSP API developments for these new OS's it appears there are some 

good things in stall - of coarse not for ham radio, but for multimedia 
running on DSP's. Fortunately we will be able to fit right into the picture 
with our work. So have good faith. 


Sorry for the distraction - this has little to do with HF digital but 
thought I would give my two cents worth. 


--Johan 


From shane@mdd.comm.mot.com Wed Oct 26 12:40:34 1994 
Return-Path: <shane@mdd.comm.mot.com> 
Received: from ftpbox.mot.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOrOCKu-O0001QRC; Wed, 26 Oct 94 12:40 CDT 
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(5.67b/IDA-1.4.4/MOT-3.1 for <hfsig@tapr.org>) 
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SMTP (5.67b/IDA-1.4.4/MOT-3.1 for <hfsig@tapr.org>) 
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Received: from daffyduck.mdd.comm.mot.com by mdd.comm.mot.com (4.1/SMI-4.1) 
id AA25083; Wed, 26 Oct 94 10:39:02 PDT 
Received: by daffyduck.mdd.comm.mot.com (4.1/SMI-4.1) 
id AA15389; Wed, 26 Oct 94 10:39:01 PDT 
Date: Wed, 26 Oct 1994 10:39:00 -0700 (PDT) 
From: Hugh Shane <shane@mdd.comm.mot.com> 
X-Sender: shane@daffyduck 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:59] Re: PSA 
In-Reply-To: <62763272701@f1r1l.orst.edu> 
Message-Id: <Pine.SUN.3.90.941026101729 .15133C-100000@daffyduck> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


> lately, so I dont know the status of that project of his. It would be real 
> nice if we can make a 9600/G3RUH modem available for the card. Perhaps you 
> should be the one do it? 


This would be a tasty project indeed! Is this the appropriate place to 
begin a discussion on this topic, or is there another SIG that would be 
better. 


Please give your thoughts on your DSP platform high priority - the learning 
curve is real steep and we will be starting to do some real stuff in the 
very near future. Let me assure you - there is a lot of fun ahead! 


VV VV WV 


In comparing DSP platforms I consider performance, features, 
compatibility, price, and availability. IMHO, for our purposes, there are 
only two contenders for a DSP platform at this time: the PSA-class boards 
and the TAPR DSP-93. The PSA solution has adequate performance, is 
reasonably priced and available now. However, it only works with ISA/EISA 
machines and is not code compatible with the TAPR product, which has a 
large code base that is certain to grow in the future. On the other hand, 
the TAPR board is twice as expensive as the PSA boards and has a lead time 
of half a year. 


If I didn't care about what the rest of the ham radio world was doing I'd 
go with the PSA solution. But I *do* care! Does it make sense to not take 
advantage of a potentially huge pool of code? Or maybe we should just 
start our own faction which will have its own devotees and its own code 
base. Maybe in time this will become the winning solution due to the low 
price and general availability of the hardware. 


I think I'll continue to sit on the fence a little while longer. Can someone 
push me off? 


Hugh 
From FORRERJ@frl.orst.edu Wed Oct 26 13:40:32 1994 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxrODGu-OO01UVC; Wed, 26 Oct 94 13:40 CDT 
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FL" <FORRERJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Wed, 26 Oct 1994 11:40:01 PST8PDT 
Subject: Re: [HFSIG:61] Re: PSA 

Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <62A6D8FOOFF@frl.orst.edu> 
Hugh, 


I see no problem discussing the 9600 baud modem stuff here, though think 
that if it concerns implementation details, the DSP development SIG 
would be the right place and may appeal to a wider audience. I think 

you will get a lot more support there too. 


In a future posting (hopefully by monday), I hope to include some important 
aspects that differentiates the VHF style DSP modems from the 
intended robust HF DSP modems. They have lots of similarities. i.e. 


phase and symbol synchronous, carrier & data extractors from supressed- 
carrier modulation systems, however, require careful design of signal 
constallation, and particulaly, robust phase locking - these are much 
more important than speed. But more on this later. 


Johan 


From gjones@tenet.edu Wed Oct 26 14:44:30 1994 

Return-Path: <gjones@tenet.edu> 

Received: from Kay-Abernathy.tenet.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOrOEGp-Q001RzC; Wed, 26 Oct 94 14:44 CDT 

Received: (from gjones@localhost) by Kay-Abernathy.tenet.edu (8.6.9/8.6.9) id 

OAAQ9751 for hfsig@tapr.org; Wed, 26 Oct 1994 14:44:22 -0500 

From: Greg Jones <gjones@tenet.edu> 

Message-Id: <199410261944 .0AA09751@Kay -Abernathy.tenet.edu> 

Subject: Re: [HFSIG:61] Re: PSA 

To: hfsig@tapr.org 

Date: Wed, 26 Oct 1994 14:44:21 -0500 (CDT) 

In-Reply-To: <Pine.SUN.3.90.941026101729 .15133C-100000@daffyduck> from "Hugh 

Shane" at Oct 26, 94 12:47:00 pm 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 4241 


According to Hugh Shane: 

> lately, so I dont know the status of that project of his. It would be real 
> nice if we can make a 9600/G3RUH modem available for the card. Perhaps you 
> should be the one do it? 


This would be a tasty project indeed! Is this the appropriate place to 
begin a discussion on this topic, or is there another SIG that would be 
better. 


VV VV VV MV 


I think you will find that the cards do not have any enough power to handle 
the 9600 baud full-duplex transmission. From what I have been told it is 
doubtfull that half-duplex can be done..maybe somebody can reply to this. 


This does not stop doing a lower baud with more bps, but current standards 
favor FSK, for a lot of reasons. I would point you at some of the last TAPR 
prcoeedings and ARRL DCC articles on 2 and 4 FSK and PSK and the like 
performance possibilities. 


> > Please give your thoughts on your DSP platform high priority - the learning 
> > curve is real steep and we will be starting to do some real stuff in the 


> very near future. Let me assure you - there is a lot of fun ahead! 


In comparing DSP platforms I consider performance, features, 
compatibility, price, and availability. IMHO, for our purposes, there are 
only two contenders for a DSP platform at this time: the PSA-class boards 
and the TAPR DSP-93. The PSA solution has adequate performance, is 
reasonably priced and available now. However, it only works with ISA/EISA 
machines and is not code compatible with the TAPR product, which has a 
large code base that is certain to grow in the future. On the other hand, 
the TAPR board is twice as expensive as the PSA boards and has a lead time 
of half a year. 


VV VV VV VV VV NV 


With hope, a mfg will pick up the DSP-93 design and mfg it for much less 
than what we are doing it for as kits. The reason for doing the DSP-93 is 
not to make money at selling kits, but to open up the technology (which 

has been the goal since 1988). With the DSP-12 from LL Grace leaving the 
market that now leaves the AEA units as the only commerically available 

unit (from amateur suppliers). 


I don't know if you can remember back to the TNC-2 introduction, but those 
kits were sold for $250+ and within two years were available for $150. 

We hope that the DSP-93 technology can happen in the same way. If the unit 
is done as all SMA technology and as one board and is done outside the US, 
I figure that cost would a lot less than what we can do it in small qtys 
and as kits. 


So - if you like the design, and dont want to either 1) wait for a kit and 

2) spend $430 (which is a bargin for what it does) then you should be 

calling up your favored mfg and asking him when they are going to talk to tapr 
about OEMing the technology :-) 


If I didn't care about what the rest of the ham radio world was doing I'd 
go with the PSA solution. But I *do* care! Does it make sense to not take 
advantage of a potentially huge pool of code? Or maybe we should just 
start our own faction which will have its own devotees and its own code 
base. Maybe in time this will become the winning solution due to the low 
price and general availability of the hardware. 


VV VV VV 


I think you will see that code is developed for all platforms and a lot of 
it will be ported between systems. The reason for going with one solution 
or another is what you want to do. If you need two radio ports, the 
interface to the radios, and processor and power to do 9600 baud full-duplex 
or the like then the DSP-93 is a solution. 


If you want to do modulations that require the A/D power but not 

all the processor power than a sound card is a good solution. Just don't 
forget that with the sound card you still need all the radio interface 
depending on what you are wanting to do...that is one reason the DSP-93 is 
more expensive to start with - it has all the interface builtin. 


> I think I'll continue to sit on the fence a little while longer. Can someone 
> push me off? 


Probably not a bad decision. If you have a modem you are happy with now, 
then you should stick with it. You will want to purchase a DSP unit if 1) 
you want to experiment and 2) there is a new mode that requires it. 

No need to purchase something that will sit around. 


Cheers - Greg 
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To: hfsig@tapr.org 


Date: Wed, 26 Oct 1994 13:01:31 PST8PDT 
Subject: Re: [HFSIG:63] Re: PSA 

Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <62BC9234604@frl.orst.edu> 
Hi Greg, 


Could you pse post the actual reference to DCC and TAPR docs that have the 
FSK/PSK performance specs for everyone's benefit - would be great - thanks. 


- Johan 
From FORRERJ@frl.orst.edu Thu Oct 27 14:54:15 1994 
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Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 


Date: Thu, 27 Oct 1994 12:53:49 PST8PDT 
Subject: DEMODULATOR TESTING ETC. 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <643A91E04AC@frl.orst.edu> 


Hi all, 


Thanks for the words of encouragement - the HFSIG is only what we make 
it to be and it is heartwarming to see that there still is amateur spirit 
to push the envelope. 


Re: the DSP platform: I hope we dont waste too much time on a silly issue 

of who has more marbles. The DSP soundcard will do 9600 baud - I dont know 
who told Greg otherwise, just to put the record straight - look at the 

Scout 14.4K modems, they use the same family DSP chip. Trying to compare 
these platforms are like comparing a Caddy to a Jeep - both will do 90 on 
the freeway, but they are ultimately for different purposes. The DSP-93 has 
excellent capabilities - especially a capable strong support group - that 

is vital if you are just starting out - lots of "free" software - and 

it could be used as a free-standing DSP box. I hope they get all the support 
to make their efforts worthwhile - that box must succeed. 


However, for those that are going to become deeply involved in the 
development and testing aspects, the DSP development platform requirements 
are going to become much more complex - for example, the real-time channel 
simulator probably will be running on its own DSP processor with input - 
output channels to take the signal from the modulator, add the simulated 
effects, and play it out in real time on the output channel to the 
demodulator under test. This probably means a DSP platform for the 
modulator and another for the demodulator. Add to that DSP diagnostic 
tools, i.e. to display parts of the signal or constallations, logging of 
results etc.... That adds up to two PC platforms and three DSP development 
systems. Perhaps you will now understand why I am using $80 sound DSP sound 
cards. If anyone can suggest another approach, I'll be really interested. 


However, if you are only planning to participate in actual over the air 
testing, a modest PC, i.e. 486/33 and either a DSP-93 or DSP sound card 
will do just fine. At this level, I am confident that code for either 
approach will be made available for you to participate in these tests. 


By monday I'll put forward a rough proposal on something that we can start 
working on - unfortunately we do not have anything yet on the simulator, but 
I have good faith that we can put something very rudimentary together that 
will do for starters. If we keep things generic, and write algorithms in 
psuedo-code, it really wont matter what platform you are going to use at 
this early stage. Actually, if we follow this approach, you can even write 
the test code in "C" and run it on your PC - it will be a lot slower and 

you wont get the same statistical sampling, but all we need to establish 
initially are the working tolerances for some of the major components. 
Hopefully things will be a lot clearer after seeing the plan. 


I also encourage folks to discuss other topics besides the digital issues - 
please feel free to do so. Also if you have other ideas on how to go about 


this journey - let us have your opinions/suggestions. 


73's 


Johan 

From muphaus@cris.com Thu Oct 27 22:11:34 1994 
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To: hfsig@tapr.org 

From: muphaus@cris.com (Marv Uphaus) 

Subject: Re: [HFSIG:65] DEMODULATOR TESTING ETC. 

Date: Thu, 27 Oct 1994 20:38:29 -0500 

Organization: CRIS via TELENET 

Reply-To: muphaus@cris.com 

Message-Id: <LO5ikCysS-LTO73yn@cris.com> 

In-Reply-To: <643A91EQ4AC@fr1l.orst.edu> 

Lines: 18 


>However, if you are only planning to participate in actual over the air 
>testing, a modest PC, i.e. 486/33 and either a DSP-93 ox DSP sound card 
>will do just fine. 


Now, Johan... 
Only a few months ago an 8088 would have been a “modest PC"... 
hahaha... My, how our perspective changes...!!! 


>I also encourage folks to discuss other topics besides the digital issues - 
See above... hahaha... 
Marv... 


-- Marv Uphaus -- muphaus@cris.com -- Ph: 205-343-9256 -- 

-- PGP Public Key available -- "finger muphaus@cris.com" -- 

-- U.S.Mail: 4031 Airport Blvd. #49 -- Mobile, AL 36608 -- 

-- Packet Radio Address -- K4BVG @W4IAX.#MOBAL.AL.USA.NA_ -- 

From gjones@tenet.edu Fri Oct 28 15:30:39 1994 
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From: Greg Jones <gjones@tenet.edu> 

Message-Id: <199410281756 .MAA14326@Kay -Abernathy.tenet.edu> 

Subject: Re: [HFSIG:65] DEMODULATOR TESTING ETC. 

To: hfsig@tapr.org 

Date: Fri, 28 Oct 1994 12:55:59 -0500 (CDT) 

In-Reply-To: <643A91EO4AC@frl.orst.edu> from "Johan Forrer 

FL" at Oct 27, 94 02:57:00 pm 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 2329 


According to Johan Forrer 

FL: 

> Re: the DSP platform: I hope we dont waste too much time on a silly issue 
of who has more marbles. The DSP soundcard will do 9600 baud - I dont know 
who told Greg otherwise, just to put the record straight - look at the 
Scout 14.4K modems, they use the same family DSP chip. Trying to compare 
these platforms are like comparing a Caddy to a Jeep - both will do 90 on 
the freeway, but they are ultimately for different purposes. The DSP-93 has 
excellent capabilities - especially a capable strong support group - that 
is vital if you are just starting out - lots of "free" software - and 

it could be used as a free-standing DSP box. I hope they get all the support 
to make their efforts worthwhile - that box must succeed. 


VVVVV VV VV 


I would be real interested in knowing if anyone has 9600 baud FSK 
implemented on a card device. From my conversations with crystal 
semiconductor, makers of several of the devices for the sound card industry, 
they felt that 9600 baud was outside the processing power of the many of the 
current low-cost devices. 


Please keep in mind that 14.4Kbps is 1200 baud with 12 bits of encoding. 

The problem we have in amateur radio applications with expanding the numbers 
of bits per baud is the medium we are using - radio. Radio and telephonic 
operations are considerably different and the S/N must be very good in 

order to be able to handle the higher order encoding methods. 


One thing we should keep in mind is the work Phil Karn is doing on using FEC 
and symbol rates in such a way to provide some rather robust links. 


Both Phil's and Tom's papers on these topics were published in 
the TAPR 1994 Proceedinsg, which I think sells for $7. I am always 
forgetting what stuff goes for. 


I think we agree that none of us should be getting into pissing contests on 
performance issues. The idea of any discussion, I would hope within TAPR, 
would be to do the research, make the informationl available, and then try 
to implement it in something that provides the widest possible access to 
amateurs in the community. 


The other main reason for not really worrying about performance issues is 
that whatever we have now - will be 2+ folds more powerful in 5 years. 


Cheers - Greg 


From jbloom@arrl.org Fri Oct 28 15:43:21 1994 
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id <2EB1002A@arrl.org>; Fri, 28 Oct 94 09:44:10 EDT 
From: "Bloom, Jon, KE3Z" <jbloom@arrl.org> 
To: hfsig <hfsig@tapr.org> 
Subject: RE: [HFSIG:65] DEMODULATOR TESTING ETC. 
Date: Fri, 28 Oct 94 09:42:00 EDT 
Message-Id: <2EB1002A@arrl.org> 
Encoding: 28 TEXT 
X-Mailer: Microsoft Mail V3.0 


Johan says: 

> If we keep things generic, and write algorithms in 

>psuedo-code, it really wont matter what platform you are going to use at 
>this early stage. Actually, if we follow this approach, you can even write 
>the test code in "C" and run it on your PC - it will be a lot slower and 
>you wont get the same statistical sampling, but all we need to establish 
>initially are the working tolerances for some of the major components. 


This is what I'm most interested in: developing and documenting the 
algorithms needed to implement all the neat things people are dreaming up, 
including the HF channel simulator and faster HF modems, but not limited to 
those applications. The algorithms can be documented in pseudo-code, flow 
charts, SDL or whatever seems appropriate. Then the algorithm can be 
implemented on multiple platforms. My feeling is that we should strive, 
where possible, to do work that is platform independent, _then_ transfer 
that work to an implementation on a specific platform. If we do a good 
algorithm design up front, it will shortly appear as an implementation on 
several platforms; there are enough programmers to make that happen. 


And, of course, I'd like to see the algorithms documented in QEX! :-) 


Regarding the HF channel simulator... it's main use (for us) is to test 
other DSP modems, so clearly it has to be running on a separate platform. 
The TI DSK strikes me as a good, cheap stand-alone platform. But, as I say, 
if we get the algorithms documented, the choice of platform is easier. 


-- Jon, KE3Z 
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Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOr10L4-0001hRC; Fri, 28 Oct 94 18:04 CDT 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id IAAQ2366 for <hfsig@tapr.org>; Fri, 28 Oct 1994 
08:42:28 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Fri, 28 Oct 94 16:03:24 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Fri, 28 Oct 94 16:03:13 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 
Date: Fri, 28 Oct 1994 16:03:07 PST8PDT 


Subject: Re: [HFSIG:67] Re: DEMODULATOR TESTING ETC. 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 

Message-ID: <65ED1C42400@frl.orst.edu> 


Hi Greg, 


You quite correctly pointed out the challenge of 9600 baud FSK ~- I do agree 
that what we presently have, would not have enough ticks to do that - 
thanks for clearing that up. 


I would like you to consider some ideas on how we can achieve reasonable bit 
rates based on low baud rates and multiple phase / multiple amplitude 
modulation, i.e. complex modulation. This would be within the capabilities 
of what we have right now. We need however, address the variablities of the 
HF channel and its affects on such a scheme. I'll put out some ideas on 
monday on the possible use of a "pilot" channel that goes out in parallel 
with the data channel to aid in phase/amplitude equalization for such 
complex modulated schemes. This is not a unique idea either. 


Oh yes, quite true - coding theory will come in a bit later in the game, 
but should not be a bandaid for a poor modulation, it should buy us that 
few extra bits "gain" on top of what we have achieved with a good 
modulation scheme. 


73's 


Johan 

From k5yfw@k5yfw.ampr.org Fri Oct 28 20:56:01 1994 

Return-Path: <k5yfw@k5yfw.ampr.org> 

Received: from k5yfw.ampr.org by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxr130c-0000q5C; Fri, 28 Oct 94 20:55 CDT 

Date: Fri, 28 Oct 94 20:19:23 CST 

Message-Id: <2123@k5yfw.ampr.org> 

From: k5yfw@k5yfw.ampr.org (Walter D. DuBose - K5YFW) 

Reply-To: k5yfw@sat.n5lyt.ampr.org 

To: hfsig@tapr.org 

Subject: HF Modulation 

X-Mailer: Bdale's Mailer version PA3AZK.940404 (MSDOS) 


Greetings HFers, 


I thought I'd try and re-name this thread from DEMODULATION to 
Modulation. Realizing however, that both are needed and in complex 
modems and both creating the modulator and detector on a sound card is 
going to be a challange. 


For those who have gotten in "late", Johan and I have been discussing 
robust, high speed modems for almost a year and Greg and I have been 


carrying on a dialog for several months now. 


I have used commercial/military equipment on HF at 2400 and 4800 BPS 


that were xvery*x robust modems. We even ran on-the-air tests against 
SITOR (the commercial version of AMTOR) over the same channel. The high 
speed modems beat SITOR in transferring data at a factor greater than 
the difference in bit rate. That is to say that at 2400 BPS for the 
robust HF modem we had 100% thruput at 2400 BPS. It was capable of 2400 
BPS data transfer rate and it transfered 2400 bps. On SITOR, we had 
less than 100% of the possible thruput rate. In Jan of 1990, the modem 
cost $15,000. Today you can get it for $3,200. 


I have seen the block diagram and chips it has and it "looks" like a 
sound card and has the same type DSP & ASP chips as soundcards. While 
probably would not want to just emulate that modem, we should improve on 
the design, we should make it a goal as we know it is achievable. 


Many of my friends ask me why I hate CLOVER. I tell them that I don't 
but feel for that amount of money, hams should get more BPS for their 
buck. Hear's the reason. CLOVER uses 4 parallel tones to get 800-900 
BPS. The commercial/military modems use 39 tones to get 2400 BPS with 
the 40th tone as an unmodulated/standard modulated pilot/doppler tone. 
I believe that some where between 4 and 40 tones hams (those of you who 
are much smarter than I) can come up with a modem for HF that will be 
very robust and produce 1200-2400 (and maybe more) BPS in a BW that is 
less than the commercial/military modem. 


If the guys who will do the actual programming "max-out" the soundcard 
and produce a robust, 2400 BPS (100 baud or less) HF modem and can apply 
the the same principle to a V/UHF modem and get 9600/19.2K BPS, ham 
radio will have greatly benefited. If they can produce only 1200 BPS on 
HF and 4800 or 9600 on V/UHF, thats Ok too...just max-out the sound 
cards capability. By then, perhaps better sound cards and/or other 
devices will be on the market that will let us go higher. 


I like the picture of the frog choking the water fowl while the frog's 
head in in the bird's mouth. The caption is never give up. Don't give 
up, try hard, keep it low cost and KISS. 


73 & have a nice weekend ya'll. 


Walt@home (dba k5y£w) 

From 70730.3472@compuserve.com Sun Oct 30 23:35:41 1994 

Return-Path: <70730.3472@compuserve.com> 

Received: from dub-img-2.compuserve.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxr1pP6-0001cTC; Sun, 30 Oct 94 23:35 CST 

Received: from localhost by dub-img-2.compuserve.com (8.6.4/5.940406sam) 
id AAA29239; Mon, 31 Oct 1994 00:35:29 -0500 

Date: 31 Oct 94 00:33:51 EST 

From: Johan Forrer <70730.3472@compuserve.com> 

To: HFSIG <HFSIG@tapr.org> 

Subject: Modulation 

Message-ID: <941031053350_70730.3472_CHK45-1@CompuServe. COM> 


Hi all, 


It is not quite so obvious which "magic" technology we should pursue 
that will give maximum gains. Well, perhaps there is no magic answer, 
or at least; those that know better won't say either or won't be 
bothered. Lets face it, most everything that we are about to 

embark on, have been done before in one form or another 

commercially - though I am not aware of anything affordable for 
amateurs to experiment with (yes, Clover could have been the 

answer, except that it was developed as a "closed" architecture). 


How one chooses one modulation/demodulation scheme over another, 
is an extensive and interesting topic by itself. Without going 
into much details, let me take an easy way out and go by what 
others have achieved, that is, m-FSK to approx 300 bps and (nxm) - 
PSK for higher rates. These have been found to be quite usable on 
HF. 


The m-FSK option, i.e. a system similar in modulation and coding 
than what is presently implemented for ALE, would be quite do- 
able on our present DSP platforms. Anyone interested in that? 


Nxm-PSK is a multitone approach. In this scheme, there are 

several (n- of them) independent m-PSK carriers. As far as 

development is concerned, one can concentrate your development 

efforts on getting the most out of one carrier, then add 

additional carriers as far as your DSP horsepower will take you, 

or perhaps until you run out of bandwidth (suspect the DSP is the limiting 
factor). The parallel deal is to be used to get maximal bit rate as conditions 
permit, or 

serve for additional redundancy when conditions are not so good. 

This basically is the premise used for the MIL-STD-188 parallel 

modems. I would (rather bravely) like to suggest that this 

alternative be pursued - unless of course you could suggest a 

better alternative. Please let me know your opinion on this one. 


Assuming the nxm-PSK approach in its simplest form, how does it sound if we 
develop a single m-PSK channel and see how far that takes 
us. ? 


I would suggest as background, obtaining the following three 
papers (these are heavy duty, but quite good): 


1) Foschini, G.J., R.D. Gitlin, and S.B. Weinstein. "On the 
Selection of a Two-Dimensional Signal Constellation in the 
Presence of Phase Jitter and Gaussian noise." Bell System Tech. 
Jour. Vol. 52(6) July-August 1973 pp:927-965. 


2) Simon, M.K., and W.C. Lindsey. "Optimum Performance of 
Suppressed Carrier Receivers with Costas Loop Tracking". IEEE 
Trans. on Communications Vol. COM-25(2) February 1977 pp:215-227. 


A more complete and realistic treatment of the performance of 
different modulation schemes and of phase lock loops in the 
presence of noise and phase jitter are also given in the above 


authors' book: "Telecommunications Systems Engineering." Dover 
pubs. ISBN 0-486-66838-X. 


3) Simon, M.K. and J.G. Smith. "Carrier Synchronization and 
Detection of QASK Signal Sets." IEEE Trans. on Communications 
Vol. COM-22(2) February 1974. 


It is evident, at least to me, that carrier phase synchronization 

and amplitude equalization becomes quite important when dealing with 
these complex (meaning quadrature) waveforms. The idea of using a separate 
"pilot" channel that carries such phasing and clock data, seems rather 
attractive. Not 

only will it simplify implementation details, but probably allow us to 
be able to track multipath effects. The additional robustness in system 
performance 

that it would add, would offset its small amount of additional 
bandwidth. Let me have your views on this one too. Also think a 

bit about what information need to be encoded in the "pilot" 

carrier. 


73's 


Johan 


PS: Thanks to Walt for forwarding a wealth of details over an extended period on 
the MIL-STD-188 modems. We certainly have beaten its possibilities to death. The 
use of the pilot tone, or doppler channel as they call it, is used in both the 
39-tone as well as 

the 16-tone modems. 


I must also thank Bill Coleman, AA4LR, for discussions on TELEBIT's PEP, and the 
use of the pilot tone for dealing with multipath effects. 


